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IBM PS/2 
Model 90 XP 486 
and 

Model 95 XP 486 

Thomas Bocchino, Louis Capps, 
Mark Shipley and Gene Troskey 
IBM Corporation 
Boca Raton, Florida 

Reprinted and adapted from 
Innovations, Issue 4,1990, 
an IBM internal publication 

This article describes the IBM Per¬ 
sonal System/2® Model 90 XP 486 
desktop system and the Model 95 
XP 486 floor-standing system, 
which both feature the Extended 
Graphics Array (XGA) video sub¬ 
system and Small Computer Sys¬ 
tem Interface (SCSI) storage 
devices. 

The Model 90 
Desktop System 

The PS/2 Model 90 XP 486 is a 
family of three expandable desktop 
systems based on the 32-bit i486™ 
processor and IBM’s Micro Chan¬ 
nel® architecture. A unique attribute 
of the system is its processor up¬ 
grade capability provided by a re¬ 
movable processor complex. The 25 
MHz system comes with an 80 MB 
or 160 MB fixed disk, and the 33 
MHz model boasts a 320 MB fixed 
disk. 

All models feature the new XGA 
graphics and 4 MB of 70 nanosec¬ 
ond (ns) standard memory. The sys¬ 


1 





Hardware 



tem can be expanded to 32 MB of 
memory on the system board, thus 
saving an expansion slot that would 
otherwise be needed for a memory 
expansion adapter. 

The system board has four 32-bit ex¬ 
pansion slots for adapter cards and 
one direct memory access (DMA) 
parallel port. It offers two DMA se¬ 
rial ports, an advantage over other 
products that offer only one stan¬ 
dard serial port. 

The IBM PS/2 Micro Channel SCSI 
Adapter with Cache is a standard 
feature. It allows the attachment of 
up to seven SCSI devices from a sin¬ 
gle adapter that occupies one of the 
four card slots. Of the four DASD 
bays that are provided, one holds 
5.25-inch, half-high devices, and the 
other three are for 3.5-inch devices. 


Two of the bays are available for 
expansion. 

The Model 90 is intended for users 
of power applications. It speeds 
through complex financial analyses 
and other numeric-intensive applica¬ 
tions. It runs power-hungry 
CAD/CAM and engineering pro¬ 
grams that require high-resolution 
imaging and graphics. And it is 
great for desktop publishing and pro¬ 
fessional presentation graphics. 

The Model 95 
Floor-Standing System 

The PS/2 Model 95 XP 486 is a top- 
of-the-line, floor-standing system 
for use as a LAN server, communi¬ 
cations gateway or bridge, or as a 
multi-user host. It is also ideal for 
users of power applications requir¬ 
ing high performance and for users 
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needing high capacity and ex¬ 
pandability. Applications include de¬ 
sign graphics, multimedia and 
financial modeling. 

The Model 95 is based on the 
Micro Channel and the 32-bit i486 
microprocessor. The 25 MHz sys¬ 
tem comes with a 160 MB or 320 
MB fixed disk drive. The other 
model runs at 33 MHz and has a 
320 MB fixed disk drive. 

The PS/2 Micro Channel SCSI 
Adapter with Cache is a standard 
feature. There are a total of seven 
bays for storage devices, which can 
hold up to five 320 MB high-speed, 
SCSI fixed disk drives, for a maxi¬ 
mum internal capacity of up to 1.6 
GB. The bays can also accommo¬ 
date CD-ROM drives, 5.25-inch 
diskette drives and tape back-up de¬ 
vices. The new PS/2 External Stor¬ 
age Enclosure for SCSI Devices 
(3511-003) can be added as an op¬ 
tion to hold an additional 2.1 GB of 
fixed disk storage. 

Like the Model 90, the system in¬ 
cludes the same upgradeable proces¬ 
sor complex and 4 MB of 70 ns 
standard memory. There are eight 
32-bit expansion slots, two of which 
are used for the standard XGA Dis¬ 
play Adapter/A and the SCSI 
adapter. There is one DMA serial 
port and one DMA parallel port on 
the system board. A 320-watt, 
worldwide power supply provides 
ample power for options. 

Parts Commonality and 
Options 

Considerable effort went into 
designing common parts for the 
desktop and floor-standing systems 
to reduce manufacturing costs and 
to ensure compatibility. The same 
two 80486-based processor com¬ 
plexes, one running at 25 MHz and 


the other at 33 MHz, are used in 
both systems. The 80486 micropro¬ 
cessor contains an internal 8 KB 
memory cache and floating-point 
processor unit. The addition of an 
optional 256 KB Cache card offers 
improved performance. 



Another unique feature of 
the Model 90 and 95 is 
that a 3 MB protected 
partition on the fixed disk 
is reserved for system 
software. 


IBM provides 2 MB and 4 MB 70 
ns memory expansion kits so that 
the amount of memory in a system 
can be increased. The kits must be 
added in matched pairs because the 
memory subsystem design uses in¬ 
terleaving to provide zero wait state 
performance. The design does parity 
checking and allows single in-line 
memory modules (SIMMs) of differ¬ 
ent speeds to be used on the same 
system board. IBM announced that 
it intends to provide 8 MB SIMMs, 
when they become available, as an 
optional feature for both systems, al¬ 
lowing a total of up to 64 MB of 
memory on the system board. IBM 
stated that it intends for OS/2 to sup¬ 
port the full memory capacity of the 
systems. 

A 3.5-inch, 1.44 MB diskette drive 
is standard on both systems. A new 
5.25-inch Slim High Diskette Drive 
option with electrical button eject 
can be used on either system. A 
unique selectable boot feature al¬ 
lows for booting from any drive. 


The 2.3 GB Full-High SCSI Tape 
Drive option was announced for the 
Model 95 and the new 3511 Exter¬ 
nal Storage Enclosure for SCSI De¬ 
vices. For systems requiring the 
ability to save/restore, archive and 
distribute data, this high-perfor¬ 
mance (245 KB-per-second data 
transfer rate), high-capacity option 
provides an attractive solution. 

The new 80 MB and 160 MB SCSI 
Fixed Disk Drive options can be 
used on Models 60, 65, 80, 90, 95 
and 3511. The 80 MB drive has two 
disks, four heads, 17 millisecond 
(ms) average seek, and a 1.35 MB- 
per-second data transfer rate. The 
160 MB drive has four disks, eight 
heads, 16 ms average seek, and a 
1.50 MB-per-second data transfer 
rate. They both have 32 KB buffers 
and use synchronous SCSI mode 
operation. 

Another unique feature of the 
Model 90 and 95 is that a 3 MB pro¬ 
tected partition on the fixed disk is 
reserved for system software. When 
the system is installed, the entire 
Reference Diskette is copied into 
this partition, along with the image 
of the Power-On Self-Test (POST) 
and the Basic Input/Output System 
(BIOS). Afterward, at initial micro¬ 
code load (IML) time, the system 
loads the BIOS program from the 
fixed disk into system memory. If 
the system encounters an error, or if 
the configuration is changed, the 
system automatically runs the IML 
code. This is much easier for the 
user because it eliminates the need 
to have the Reference Diskette 
available. 

This IML feature also makes it eas¬ 
ier to upgrade BIOS in the future. 
Instead of BIOS being in erasable 
programmable read-only memory 
(EPROMs) on the processor com¬ 
plex, it resides in a file format on 
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PS/2 Model 95 XP 486 Floor-Standing System 


the fixed disk. The Reference Disk¬ 
ette with the new image of BIOS is 
all that is needed for upgrading. 

Competitive Strengths 

One of the major competitive 
strengths of Models 90 and 95 is 
the removable processor complex. 
This provides investment protection 
for the owner because it extends the 
life of the system over time. As pro¬ 
cessor performance becomes critical 
to overall system throughput, the 
system can be upgraded with a new 
processor complex. 

Another major strength comes from 
XGA as the new video subsystem 
for the PS/2 family of Micro Chan¬ 
nel products. XGA is an evolution 
of the Video Graphics Array (VGA) 
offered on the first PS/2 systems. It 
is a high-performance, 32-bit DMA 
bus master that is compatible with 
existing VGA applications and with 
the 8514/A Adapter Interface. With 
a 14-inch PS/2 8515 Color Display 
or a 16-inch PS/2 8514 Color Dis¬ 
play, it can display images in 1024 
by 768 resolution with 256 colors. 

It also drives the other PS/2 mono¬ 
chrome and color displays. 

XGA is optimized for use by win¬ 
dow managers and other graphical 
user interfaces. It is significantly 
faster than VGA in a DOS environ¬ 
ment, and its software improves per¬ 
formance even more in a windowed 
environment. The result is a graph¬ 
ics subsystem that more than dou¬ 
bles the number of picture elements 
while improving response time. 

A PS/2 XGA Display Adapter/A is 
available as an option for Models 
55, 65, 70, 80, 90 and 95. A PS/2 
Video Memory Expansion Option 
can be added to the card to upgrade 
it to 256 colors at 1024 by 768; this 
maximum memory configuration is 


standard for some foreign countries. 
The adapter comes with device driv¬ 
ers for DOS, OS/2 Presentation 
Manager™ and Microsoft® Win¬ 
dows™. Numerous vendors intend to 
update their applications to work 
with XGA. 

Models 90 and 95 are the fastest 
personal systems IBM has ever of¬ 
fered. IBM has made available a 
performance guide to summarize 
the results of its extensive perfor¬ 
mance measurements with various 
applications, operating systems and 
configurations. One example from 
the guide says that the Model 95- 
0KD runs AutoCAD®, Release 10, 
in a DOS environment with a perfor¬ 
mance improvement of up to 808 
percent when compared to the refer¬ 
ence Model 50-061. 


Figure 1 shows the relative perfor¬ 
mance of DOS applications run on 
the new and previously announced 
PS/2 systems, compared to the PS/2 
Model 50-061. The bar for each sys¬ 
tem indicates the range of perfor¬ 
mance for various applications from 
the slowest to the fastest. (The Per¬ 
sonal System/2 Performance Guide, 
order number G326-0041, is avail¬ 
able through IBM branch offices.) 

The 320 MB SCSI fixed disk drive 
has a media data transfer rate of 2.0 
MB per second with a very fast av¬ 
erage seek time of 12.5 ms. It has a 
rotary voice coil actuator, closed 
loop servo, 1:1 sector interleave, a 
64 KB buffer and self-diagnostics. 
The 32-bit bus master SCSI adapter 
has a maximum SCSI data transfer 
rate of 5 MB per second. 
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Other PS/2 Models 

Other PS/2 models use larger-capac¬ 
ity fixed disk drives. The Model 65 
SX uses the 320 MB SCSI fixed 
disk, making it an ideal low-end 
LAN server for a departmental net¬ 
work. The Model 80 386 20 MHz 
and 25 MHz versions using the 120 
MB fixed disks are being replaced 
by new models using the 160 MB 
fixed disk; it also offers a new 80 
MB model to replace the original 
60 MB model. 

On the other end of the scale, a new 
Model 55 LS was introduced with¬ 
out diskette drives or fixed disk 
drives for the LAN market, al¬ 
though data storage devices can be 
easily added as options. It comes 
preconfigured with an 1133 Token- 
Ring 16/4 Adapter/A or a 1091 


Adapter/A for Ethernet networks. 
This makes installing the system in 
the network as simple as plugging it 
in. The user’s files and programs 
are protected by a pre-installed re¬ 
mote program load feature. 

Operating System Support 

Operating system support is pro¬ 
vided by Disk Operating System 
(DOS) Version 3.3 and Version 4.0, 
OS/2 Standard Edition 1.2 and 1.3 
and OS/2 Extended Edition 1.2 and 
1.3. LAN server support is provided 
by OS/2 LAN Server 1.3 and popu¬ 
lar alternatives from independent 
software vendors. 

OS/2 Version 1.3 requires only a 2 
MB memory base, yet runs up to 25 
percent faster than earlier versions. 
Users who may have needed 3 to 7 


MB of memory can now run with 2 
to 6 MB, saving 1 MB across the 
range. Users who previously needed 
more than 8 MB of memory can 
now save 2 MB. With a new selec¬ 
tive install feature, the user can 
leave out functions that he does not 
need when installing OS/2 on his 
fixed disk; this can save up to 4 MB 
of fixed disk storage. 

In addition, OS/2 1.3 features a 
built-in Adobe Type Manager™ that 
facilitates the addition of scalable 
PostScript™ fonts for display and 
printer support. This provides the 
ability to display and print text of 
any size. Another convenient fea¬ 
ture for programmers is that the 
REXX procedures language pre¬ 
viously available only in the Ex¬ 
tended Edition of OS/2 1.2 is now 
available in the base version, OS/2 
Standard Edition 1.3. 

DOS 3.3 and OS/2 1.1 support up 
to two fixed disks; DOS 4.0 and 
OS/2 1.2 support up to seven fixed 
disks and OS/2 1.3 supports up to 
24 SCSI storage devices. 

A Novel Approach to 
System Board Design 

The PS/2 Model 90 XP 486 and 
Model 95 XP 486 were designed to 
meet customers’ requirements for 
enhanced video graphics, memory 
and media expansion, processor ver¬ 
satility, and to provide system 
longevity. 

I/O Enhancements: Both system 
boards, shown in Figures 2 and 3, 
contain new, enhanced serial and 
parallel ports with direct memory ac¬ 
cess (DMA) capability. This feature 
significantly increases the through¬ 
put of the system by allowing the 
I/O controller to transfer blocks of 
data, rather than single bytes. This 
frees the system microprocessor to 
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Figure 1. Overall Performance in the DOS-Based Environment 
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work on other activities while the 
I/O information is being sent or re¬ 
ceived. By using DMA, system in¬ 
terrupts that occur after blocks of 
data - rather than single bytes - are 
ready to transfer. 

The serial ports also have a new 
high-speed data capability to com¬ 
plement the DMA feature. The 
ports can transmit and receive data 
at 345.6 kilobits per second (kbps) - 
significantly faster than the 19.2 
kbps provided by previous designs. 

The Model 90 also has a second (9- 
pin) serial port because many con¬ 
figurations require a second port for 
modems or serial plotter devices. 
Model 95 also has additional Micro 
Channel slots in which a second se¬ 
rial card can be installed. 

Keeping Time: The time-of-day 
(TOD) clock was implemented 
using an alternative technology, 
which consumes much less power, 
requiring a smaller-capacity battery 
to retain the data. The design uses 
almost 100 times less power in 
standby mode, allowing the use of a 
“coin-cell” type battery, which is 
less expensive and easier to replace. 
The battery life is also much longer, 
requiring replacement only every 
five to six years instead of the two 
to three years required by most ex¬ 
isting designs. The size of the non¬ 
volatile RAM (NVRAM) has been 
increased from 2 KB to 8 KB in an¬ 
ticipation of future requirements. 

Diskette Enhancements: Several 
enhancements were made to the 
floppy disk subsystem. The new 
Intel® 82077 floppy disk controller 
provides high reliability and lower 
cost, while out-performing its prede¬ 
cessors. The controller has DMA ca¬ 
pability, with an internal 16-byte 
first in, first out (FIFO) and internal 
phase-locked loop. The output buff¬ 


Figure 2. Model 90 XP 486 System Board 


ers are located on-chip, eliminating 
the cost of external drivers. The 
DMA feature is software-controlled, 
allowing the controller to run in in¬ 
terrupt mode if necessary. The inter¬ 


nal phase-locked loop is designed to 
switch automatically between data 
rates, which allows the use of differ¬ 
ent devices such as 5.25-inch disk¬ 
ette and tape drives. 
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Selectable Boot: A “boot-map¬ 
ping” function has been added, 
which allows the system to start 
from any of the installed fixed disks 
or floppy disks. This important fea¬ 
ture allows customers to boot the 
system from any drive, including 
the 5.25-inch floppy. The boot se¬ 
quence is configured by the user 
during setup, and stored in NVRAM. 

Common Interface: The common 
processor card feature is probably 
the most differentiating aspect of 
the design. The intent was to pro¬ 
vide a system with upgradeable pro¬ 
cessing, without adding extra cost 
to the base product. To do this, the 
system had to be divided into pro¬ 
cessor versus I/O function, and then 
a logical breaking point had to be 
defined (Figure 4). 

The processor interface has been 
kept simple to allow flexibility in 
the processor card design. The inter¬ 


face has two parts, a Micro Channel- 
type bus on one side and a system 
memory bus on the other. The pro¬ 
cessor card contains the “brain” of 
the system: the DMA controller, 
memory management, the micropro¬ 
cessor and cache. The system board 
contains I/O ports, interrupt control¬ 
ler, TOD clock, system timers, and 
the diskette controller. 

The memory portion of the interface 
supports both parity and Error Cor¬ 
rection Code (ECC), up to eight 
memory expansions in a wide array 
of sizes and speeds. The type, speed 
and size of the memory are deter¬ 
mined by the memory controller on 
the processor card. The system 
board simply buses the signals be¬ 
tween memory and the processor 
card. Memory is located on the sys¬ 
tem board in Model 95, and on 
“tower” cards in Model 90. The 
tower cards make the most efficient 


use of the available system space. 
The vertical design provides two 
very important benefits: 

• Memory upgrades are easier than 
on previous systems. The riser 
cards on the Model 90 are di¬ 
rectly accessible with the system 
cover removed. 

• Reliability is also improved be¬ 
cause memory runs cooler by 
being in the direct channel of air¬ 
flow. 

A Platform for Future Systems: 

The system boards of these new sys¬ 
tems provide significant improve¬ 
ments to previous solutions. The 
versatility of these designs assures 
that they will be platforms for fu¬ 
ture systems. 
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Figure 4. Common Interface for Models 90 and 95 
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Electrical Characterization 
of the Models 90 XP 486 
and 95 XP 486 

To develop the fastest, most reliable 
PS/2s to date, the development team 
gave special focus to the area of sig¬ 
nal quality. High-speed digital de¬ 
signs must take into account the 
physics of sending a high-speed dig¬ 
ital signal across a printed circuit 
board. 

At sufficient transition speeds, send¬ 
ing a pulse of electricity down a 
printed circuit board wire is like 
dropping a stone into a small pond. 
Ripples are generated, which can 
bounce back and forth in the line be¬ 
fore “dampening” out. This phenom¬ 
enon is referred to as 
“transmission-line effects.” In a 
pond, all that happens is a couple of 
fish are frightened, but signal ring¬ 
ing and undershoot in an electrical 
circuit can cause system malfunc¬ 
tions and even component failure. 

Electronic Eyes: To isolate and 
eliminate signal quality problems in 
a PC design, it is first necessary to 
“see” them. After building the physi¬ 
cal prototype, the development team 
characterized the prototype’s electri¬ 
cal parameters, giving special em¬ 
phasis to timing, ringing, 
undershoot and overshoot. 

The newest “weapon” available to 
the designers for performing this 
task is the digital oscilloscope. The 
digital oscilloscope differs from the 
older analog scopes in that the in¬ 
coming waveform is digitally sam¬ 
pled and stored in memory. This 
allows greater freedom to both trig¬ 
ger on a specific waveform of inter¬ 
est and to manipulate the captured 
waveform on the screen. 

Now That's Fast! Since no single 
type of oscilloscope can perform 


every task optimally, two types 
were used. One has a very wide 
bandwidth; the other has a high sam¬ 
pling rate. Bandwidth is the fre¬ 
quency at which the instrument 
attenuates the incoming signal 3 db. 
The bandwidth of the digital oscillo¬ 
scopes used to characterize the 
Model 90 and 95 systems was 1 
GHz. This scope, effective for mea¬ 
suring repetitive signals, was used 
the majority of the time. However, 
because of its lower sampling rate 
(10 million samples per second), 
this scope was not used to capture 
single events. 

To capture single events, the team 
used what is known as a “single 
shot” digital oscilloscope, which has 
a very high sampling rate (1 billion 
samples per second). This instru¬ 
ment is useful for capturing single 
events and displaying them accu¬ 
rately, but does not have the wide 
bandwidth of the repetitive 
oscilloscope. 

A Probing Issue: Another critical 
aspect of performing high-speed sig¬ 
nal measurements on the new sys¬ 
tems was the type of oscilloscope 
probes used. The oscilloscope 
probes can have a tremendous effect 
on the waveform that appears on 
the screen. In order to minimize the 
effect on the circuit to be measured, 
the probe capacitance should be 
kept to the absolute minimum, 
along with the ground lead induc¬ 
tance. Depending on the type of os¬ 
cilloscope, either active probes or 
100:1 passive probes were used. 

Both probes had capacitances below 
2.5 pf. Additionally, special ground 
clips were used to keep ground lead 
inductances to minimal values. 

Quality Leadership: Special atten¬ 
tion was given to the details of sig¬ 
nal quality by the development 
team. The end result was that the 


team was able to identify early in 
the prototype stage which signals 
needed special attention to improve 
system reliability. Changes to the 
final level of printed circuit boards 
included rerouting certain nets to de¬ 
crease the signal flight time, 
rebuffering, or adding termination 
to the nets. This effort will show up 
in the form of improved reliability. 

Advanced i486 Processor 
Complexes 

The IBM PS/2 Model 90 XP 486 
desktop system and the Model 95 
XP 486 floor-standing system use 
new technology and interface tech¬ 
niques to optimize performance of 
the 80486 microprocessor. 

The new systems offer greater lev¬ 
els of flexibility with a “processor 
complex” upgrade strategy that al¬ 
lows a wide range of processor per¬ 
formance in both the floor-standing 
and desktop systems. 

Standard on the Model 90 and 95 is 
a high-performance 25 or 33 MHz 
80486 processor complex. A 33 
MHz 80486 processor complex up¬ 
grade option for the 25 MHz sys¬ 
tems is also available. 

Processor Complex: The 25 and 
33 MHz 80486 processor com¬ 
plexes take advantage of the new 
Processor Complex Interface avail¬ 
able on the Model 90 and 95 system 
platforms to offer a memory subsys¬ 
tem optimized for the 80486. 

In addition to Multi-Level Memory 
Interleave, these processor com¬ 
plexes support a 256 KB second- 
level cache for improved 
performance in a multitasking, mul¬ 
tiple bus master environment. The 
processor complexes also improve 
system usability by supporting auto¬ 
matic single in-line memory module 
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Figure 5. Two-Way Banked Memory Interleave Architecture 


(SIMM) configuration, SIMM-spe¬ 
cific parity error logging, and the 
initial microcode load (IML) soft¬ 
ware strategy. 

Common parts used between the 25 
and 33 MHz processor complexes 
and the ability to use the same pro¬ 
cessor complex in either the Model 
90 or 95 system have reduced manu¬ 
facturing assembly and debug time 
for four different system 
configurations. 

Multi-level Memory Interleave: 

The 25 and 33 MHz 80486 proces¬ 
sor complexes use features of the 
new Processor Complex Interface 
and a custom complex memory con¬ 
troller to implement two types of 
memory interleaving that optimize 
processor performance when access¬ 
ing system board memory in a multi¬ 
ple bus master system. 


The first level of memory interleav¬ 
ing is two-way banked memory in¬ 
terleaving, which improves 
performance by reading two 32-bit 
banks of memory simultaneously 
and then feeding the data to the 
80486 one 32-bit doubleword after 
the other (Figure 5). 

When a 32-bit doubleword is read 
from one bank, the other bank is 
also read, and its results are tempo¬ 
rarily stored in a memory buffer 
latch. 

If the 80486 is reading consecutive 
memory locations, the next 32-bit 
doubleword will come from the 
memory buffer latch without the 
added delay of a memory access. 

Since the 80486 processor uses the 
new burst read technique (not avail¬ 


Model 95 XP 486 
(25 or 33 MHz) 


CPU Cycle 
Bus Master Cycle 


Previous PS/2 
Systems 

CPU Cycle 

Bus Master Cycle 



□ 


Indicates 

Concurrency 


Figure 6. Increased Processor and Bus Master Concurrency in an Environment Where 
the PS/2 System Is Used as a Server 


able in the 80386), it typically re¬ 
quires four consecutive 
doublewords of data to fill its cache 
and instruction prefetch queues. The 
combination of the 80486 burst 
cycle and the two-way banked mem¬ 
ory interleaving allows the 80486 to 
read four doublewords in the time it 
would take to do four independent 
reads. 

Second-level memory interleave is 
active only when a bus master 
“owns” the Micro Channel. This 
type of interleave allows alternating 
simultaneous system board memory 
requests from the current bus master 
and the processor. 

Earlier PS/2 systems locked the pro¬ 
cessor out completely from system 
board memory as soon as a bus mas¬ 
ter gained control of the Micro 
Channel. The processor could run 
out of the cache during this time on 
systems with cache, but as soon as 
there was a cache miss or a write 
cycle to system board memory, the 
processor was halted until the bus 
master released the Micro Channel 
to the processor. The 25 and 33 
MHz processor complexes can inter¬ 
leave system board memory 
accesses from the processor with 
system board memory accesses 
from the bus master during the time 
the bus master “owns” the Micro 
Channel instead of locking out the 
processor from system board mem¬ 
ory. This type of interleaving in¬ 
creases the concurrency between the 
processor and bus masters. 

Figure 6 shows the performance 
gained using second-level memory 
interleave. While the CPU performs 
network searches in memory (CPU 
cycles), data can be transferred con¬ 
currently to a requester on the net¬ 
work with a communications bus 
master card (bus master cycles). 
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Second-level Cache Provides 
Second Try: In addition to the 8 
KB cache that is integral to the 
80486 processor and standard on 
the 25 and 33 MHz processor com¬ 
plexes, a 256 KB second-level 
cache is offered as an option for ei¬ 
ther processor complex. The op¬ 
tional cache provides a wider area 
of fast storage for improved perfor¬ 
mance in multitasking operating sys¬ 
tem environments. 

When the cache option is installed, 
any read cycles that miss in the 
80486 internal cache are forwarded 
to the optional cache for a second 
try. If the data is present in the op¬ 
tional cache, the 80486 reads the in¬ 
formation in zero wait-state cycles. 
The second-level cache uses a two- 
way set associative algorithm and 
can transfer four 32-bit 
doublewords to the 80486 (using 
burst read) in five cycles. 

Pick a SIMM, Any SIMM: The 

25 and 33 MHz processor com¬ 
plexes support a variety of parity- 
check SIMM types with speeds 
ranging from 70 to 85 nanoseconds 
and sizes from 1 to 8 MB per 
SIMM. This flexibility, along with 
the eight SIMM sockets provided in 
Models 90 and 95, allows the sys¬ 
tem board to hold from 2 to 64 MB 
of high-speed, interleaved cached 
memory. Automatic SIMM configu¬ 
ration shields the user from com¬ 
plex set-up procedures by using a 
software algorithm to poll the 
SIMM types and configure the mem¬ 
ory controller for optimum perfor¬ 
mance based on each SIMM's 
speed and size. The only require¬ 
ment is that the user install SIMMs 
in matched pairs (both SIMMs in a 
pair are the same type) to support 
the two-way banked memory 
interleave. 


For added performance, the 25 and 
33 MHz processor complexes sup¬ 
port dynamic memory speed adjust¬ 
ment to change the cycle time for a 
SIMM access on a cycle-by-cycle 
basis. So, if fast and slow SIMMs 
are installed in the same system, the 
fast SIMMs are accessed with 
shorter cycles than the slower 
SIMMs. 



Automatic SIMM 
configuration shields the 
user from complex set-up 
procedures. 


Improved Parity Checking: 

Parity-check errors on previous 
PS/2 systems locked up the system 
with no indication of which SIMM 
contained the failing bit. Now, the 
25 and 33 MHz processor com¬ 
plexes implement SIMM-specific 
parity error logging by latching the 
select line for the SIMM that gener¬ 
ated the parity error, allowing the 
non-maskable interrupt handler to 
save the SIMM socket number in 
battery-backed RAM so that when 
the system is restarted, diagnostics 
can inform the user of the failing 
SIMM. Future operating system sup¬ 
port of this feature will allow the op¬ 
erating system to determine which 
tasks can be closed without error be¬ 
fore shutting down the system. 

BIOS Upgrade Capability: In the 

past, Basic Input/Output System 
(BIOS) upgrades were difficult to 
distribute because a change to the 
read-only memory (ROM) was re¬ 
quired. The new PS/2 systems offer 
a new I ML system software strategy 


that allows BIOS to be updated 
with a diskette, and setup and diag¬ 
nostics to be run directly from the 
hardfile. 

Previous PS/2 systems supported all 
of Power-On Self-Test (POST) and 
BIOS in ROM. The IML strategy 
present in the new systems supports 
two stages of POST code. Stage 1 
of IML is located in ROM on the 
processor complexes and consists of 
only Stage 1 POST code. Stage 2 is 
located on the hardfile and consists 
of the second part of POST and all 
of BIOS. After the Stage 1 code is 
executed. Stage 2 is loaded and 
overlays Stage 1 in RAM. After the 
Stage 2 POST code executes, the op¬ 
erating system is started, or if an 
error occurred during any part of 
POST, setup is automatically run 
from a special system partition lo¬ 
cated on the hardfile, and the error 
code is explained. The system parti¬ 
tion is new to PS/2 systems and al¬ 
lows part of the hardfile to be 
reserved by the system to hold 
setup, diagnostics and the Stage 2 
IML code that contains BIOS and 
POST. 

Parts Commonality: A continuing 
goal with PS/2 designs is to assist 
manufacturing with increased test¬ 
ability and decreased manufacturing 
overhead and debug time. The new 
processor complexes support this ef¬ 
fort by having many common parts, 
including the ROM that holds the 
POST code. Because of this, not 
only does the same processor com¬ 
plex fit in either the Model 90 or 
Model 95 system with no changes, 
but the same second-level cache op¬ 
tion will also fit on either the 25 or 
33 MHz processor complex. This 
type of commonality offers manu¬ 
facturing fewer hardware differ¬ 
ences to support four system types 
and enables the user to upgrade 
from a 25 MHz to a 33 MHz proces- 
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sor complex without changing any 
other options in the system. 

The new 25 and 33 MHz processor 
complexes used in the PS/2 Model 
90 and Model 95 systems are a 
strong statement that IBM is creat¬ 
ing new levels of performance and 
flexibility. The multi-interleaved 
memory interface, optional 256 KB 
second-level cache and 64 MB 
memory expansion on the system 
board show that the new processor 
complexes are high performers. Up¬ 
grade capability from a 25 MHz pro¬ 
cessor complex to a 33 MHz 
processor complex and multiple 
SIMM configurations protect the 
customer’s investment. Improved 
SIMM isolation at parity error time 
and automatic boot of setup and di¬ 
agnostics from the hardfile will in¬ 
crease customer confidence in 
system reliability. Finally, common¬ 
ality between the 25 and 33 MHz 
processor complexes and the op¬ 
tional second-level cache improve 
manufacturability both at debug and 
assembly time. 

The processor complex strategy is 
IBM's response to customer require¬ 
ments for high performance and in¬ 
vestment protection in its PS/2 
systems. 

Advanced Technology 
Demonstrations 

The breadth and depth of the PS/2 
system platforms and their tremen¬ 
dous growth potential and flexibility 
have been shown in a variety of 
demonstrations by IBM. 

One demonstration was a glimpse 
into the future, using a Model 95 
XP 486 based “Super-Server.” It 
was connected to a Model 90 XP 
486 and two Model 55 LS systems 


as clients on an IBM 16-megabit- 
per-second Token-Ring LAN. 

The Model 95 XP 486 was config¬ 
ured with advanced technology op¬ 
tions and an advanced version of 
OS/2 LAN Server 1.2 currently in 
beta test. It contained an Aox® 
Micromaster™ 80486 coprocessor 
and an advanced IBM bus master 
Token-Ring LAN adapter. Two 32- 
bit bus master SCSI adapters con¬ 
trolled nine 320 MB SCSI fixed 
disk drives, housed in the new 3511 
DASD enclosure. They also con¬ 
trolled a 600 MB CD-ROM drive 
and an internal 2.3 GB full-high 
SCSI tape drive. All of this was pro¬ 
tected with a vendor-developed, 
uninterruptable power supply. 

One Model 55 LS was “rippled” 
(from RIPL, remote initial program 
load) or started up by transferring 
the OS/2 operating system over the 
LAN. The second Model 55 LS was 
started by transferring the DOS op¬ 
erating system over the LAN. In 
both cases, the program and data 
files remained on the server, not on 
the workstation; this approach leads 
to a greatly reduced workstation in¬ 
vestment for the customer. 

In another demonstration, the Model 
90 XP 486 and the two Model 55 
LAN stations simultaneously pre¬ 
sented real-time, full-motion video 
data transfer at 30 frames per sec¬ 
ond over the LAN using the Action- 
Media® Adapter. This 
demonstration vividly showed the 
power and flexibility of IBM's new 
personal systems, a rapid evolution 
from the first IBM Personal Com¬ 
puter, announced in August 1981, 
nine short years ago. 


A Glimpse at the Future 

Personal systems have come a long 
way in the last decade, and industry 
forecasters project equally awesome 
advances in the next decade. In 10 
years, personal systems may be 
built with microprocessors contain¬ 
ing 100 million transistors, execut¬ 
ing 2 billion operations a second at 
clock rates of 250 MHz. Memory 
chips are likely to have from 256 
Mbits to 1 Gbit each. 

IBM will undoubtedly apply the 
same creativity and enthusiasm to 
these future challenges. 
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Choosing an I/O 
Bus Architecture 

Patsy A. Bowlds, Ph.D. 

IBM Corporation 
Boca Raton , Florida 

This article contains guidelines 
for choosing a personal computer 
architecture. It points out some of 
the issues and transition chal¬ 
lenges. The article is based on a 
portion of a new book titled Micro 
Channel Architecture: Revolution 
in Personal Computing. Informa¬ 
tion about the book follows the 
article. 

“Which bus to take?” is a prime 
topic for discussion in almost every 
organization and continues to be the 
subject of numerous articles in the 
trade press. This decision forms the 
basis for the purchase of billions of 
dollars of equipment in the ’90s and 
will affect almost every aspect of in¬ 
formation management in the com¬ 
ing decade. 

The list of major contenders for 
small systems includes Micro Chan¬ 
nel architecture, the AT® bus, the 
Extended Industry Standard Archi¬ 
tecture (EISA), and Apple’s® 

NuBus. The book on which this arti¬ 
cle is based contains an in-depth 
comparison of the technical merits 
of these bus architectures. What fol¬ 
lows here are some useful guide¬ 
lines for choosing a bus architecture 
for small systems, with emphasis on 
some of the nontechnical factors. 

Most systems in use today are AT 
bus systems and industry estimates 
project that Micro Channel systems 
will continue to dominate the 32-bit 
bus environment through 1993. 
Therefore, in this article, the focus 
for managing transitions is on the re¬ 
lationships between these two buses. 


Why Choose? 

At this point, you may wonder 
“Why even make a choice?” The an¬ 
swer is driven by a number of fac¬ 
tors that relate to how computers 
are used and technology advances. 
There are a number of forces in the 
early 1990s that will drive a change 
from earlier personal computer 
buses: 

• The 386 and, later, 486 systems 
will replace 286 and 386SX sys¬ 
tems as the entry-level worksta¬ 
tion. (You don’t have to look 
very far into the future to see this 
one!) 

• High-frequency (>25 MHz) 32- 
bit systems will dominate the 
mid-range, technical workstation 
and server environment with in¬ 
creasing presence of RISC 
processors. 

• Multitasking 32-bit operating sys¬ 
tems (OS/2, UNIX®) will use and 
require the features of advanced 
I/O bus architectures delivering 
significant performance benefits. 


• I/O-intensive applications, such 
as page printing, multimedia, and 
image processing, will drive 32- 
bit I/O requirements at the per¬ 
sonal workstation level. 

• Migration of function from main¬ 
frame systems to “personal com¬ 
puters” (both stand-alone and 
networked) and advanced work¬ 
stations will impose stringent reli¬ 
ability, data integrity, and 
fault-tolerant requirements. 

These trends are already present to 
some degree. It is clear that today’s 
purchase decisions should be made 
with these directions in mind, if at 
all possible. Even though the major¬ 
ity of systems used today are based 
on the AT bus, they simply cannot 
address these directions adequately. 
A choice must be made. What is the 
best choice, and when and how it 
should be made, are the real 
questions. 

Disposable Computers? 

One aspect that may concern you is 
the rate of obsolescence of equip- 
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ment. Why not buy the cheapest sys¬ 
tems available and “throw them 
away” in a couple of years? Why 
plan for the future with today’s pur¬ 
chases? You probably already know 
the answers. Look around and 
you’ll see that all that “obsolete” 
equipment is still with you. You re¬ 
ally don’t throw it away, you just 
live with it. That’s why it’s so im¬ 
portant to purchase equipment that 
complements your future direction 
instead of inhibiting it. 

Which Bus to Take? 

Part of the answer lies in the techni¬ 
cal merits of the various choices 
that have been discussed at length 
in a number of publications. Most 
of these publications conclude that 
Micro Channel architecture has sig¬ 
nificant technical advantages. These 
conclusions, however, are some¬ 
what rhetorical. In most organiza¬ 
tions, it’s not possible to instantly 
convert to a 32-bit bus standard re¬ 
gardless of its technical merits. 
Today’s environments are a com¬ 
plex mixture of systems with widely 
varying user requirements. How to 
effectively use AT and Micro Chan¬ 
nel systems in the same organiza¬ 
tion and manage the migration to 
Micro Channel architecture in the 
“real world” interests us all. 

These topics will be especially inter¬ 
esting for MIS managers and those 
responsible for equipment purchases 
and inventory management. 

The Ideal Computer 
Architecture 

What makes an architecture good 
(or bad, for that matter)? The first 
requirement for a computer architec¬ 
ture is to define a set of rules that 
provide hardware and software com¬ 
patibility for systems based on it. 
After compatibility, there are a myr¬ 
iad of attributes that are important. 


One of these attributes is affordabil¬ 
ity. The best architecture imaginable 
is of little use if it is not affordable 
for its intended applications. While 
it is desirable for a computer archi¬ 
tecture to accommodate a broad 
range of features and functions, cost- 
effective implementations should be 
possible. Ideally, the higher cost ele¬ 
ments of an architecture should be 
optional features that can be added 
without affecting compatibility with 
other implementations. 



The limits of an 
architecture should be 
extendable in order to 
accommodate improved 
design concepts that may 
not be invented yet. 


Another important attribute of a 
computer architecture is its data in¬ 
tegrity characteristics, or ability to 
handle information without error. 

For example, an extra or a missing 
bit of information could mean the 
difference between $100,000 or 
$1,000,000 in a banking transaction 
- a nontrivial sum! An erroneous in¬ 
struction can cause an addition to 
be performed instead of a subtrac¬ 
tion. An incorrect address could re¬ 
sult in a confidential message sent 
to the wrong person on a local area 
network. At the minimum, a com¬ 
puter system should be able to indi¬ 
cate that an error condition has 
occurred. 

Some architectures focus on ease of 
use as a primary attribute. The soft¬ 
ware architecture of Apple’s Macin¬ 
tosh® focused on a graphical user 


interface with mouse support to pro¬ 
mote ease of use. Another example 
is found in Micro Channel 
architecture’s automatic configura¬ 
tion feature, which simplifies the set¬ 
up of systems and the installation of 
expansion boards. 

An architecture should provide for 
expandability of a computer system. 
The ability to add performance or 
functions to a system is extremely 
important. Some examples of ex¬ 
pandability in computer architecture 
include the number of expansion 
slots, supported I/O devices, multi¬ 
processor support, and maximum 
storage capacity. 

Another good attribute is extendabil- 
ity. The limits of an architecture 
should be extendable in order to ac¬ 
commodate improved design con¬ 
cepts that may not be invented yet. 
An example of this is the use of re¬ 
served pins in connector design. Re¬ 
serving pins for future use allows 
for the addition of function that is 
not currently defined. 

Flexibility is also an important attri¬ 
bute. An architecture should have a 
wide range of design and applica¬ 
tion alternatives. The original PC ar¬ 
chitecture lacked flexibility because 
it could be used only with the 4.77 
MHz 8088, and its I/O bus could 
handle only 8-bit transfers. The con¬ 
sequence was that a major redesign 
was required for the IBM PC AT® 
with its faster 16-bit 80286 micro¬ 
processor. In addition to promoting 
a broad range of implementation 
possibilities, flexibility and ex- 
tendability enhance the longevity of 
an architecture. 

Another factor that enhances the 
value of an architecture is its accep¬ 
tance by the industry and by a criti¬ 
cal mass of users. One reason for 
the success of the original IBM Per- 
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Figure 1. Computer Architecture Characteristics (not prioritized) 


sonal Computer was its acceptance 
by the industry and the standardiza¬ 
tion that it brought. Industry and 
user acceptance go hand in hand. 

The greater the number of potential 
users, the greater the financial op¬ 
portunity for developers of add-on 
hardware and software applications. 
The availability of such products 
further increases a system’s value. 

A good computer architecture 
should provide a growth path and in¬ 
vestment protection for the individ¬ 
ual systems based on it. The ability 
to upgrade system performance or 
change its function enhances the 
value of a computer system and pre¬ 
vent its obsolescence. 

Performance capabilities of an archi¬ 
tecture are also important. This is 
probably the attribute most affected 
by the limits of an architecture. Add¬ 
ing higher speed processors, more 
memory, or advanced operating sys¬ 
tems are examples of how an archi¬ 
tecture can affect performance. 

Reliability, availability, and service¬ 
ability (IBM uses the acronym 
RAS) are also important attributes 
of computer architectures. Reduc¬ 
tion of failure rates and fault-toler¬ 
ant capabilities are other benefits of 
a good architecture. Problems 
should be easy to diagnose and ser¬ 
vice should be quickly and easily 
performed. 

A perfect architecture incorporating 
all of these attributes can never be 
achieved. Les McDermott, one of 
IBM’s lead Micro Channel archi¬ 
tects, says “The ideal computer ar¬ 
chitecture supports an infinite 
number of functions, has unlimited 
performance capabilities, and costs 
absolutely nothing.” Trade-offs be¬ 
tween cost and function must al¬ 
ways be made. For example, an 
architecture suitable for super¬ 


computers is unsuitable for personal 
computers. The challenge is to find 
the right balance. 

An interesting exercise is ranking 
the characteristics of an ideal archi¬ 
tecture. As you will discover, bal¬ 
ancing the characteristics of the 
ideal computer architecture is a non¬ 
trivial task. But this is the same 
kind of exercise that IBM market¬ 
ing, engineering, programming, 
product planning, manufacturing, 
and service engineers faced when 
they defined Micro Channel 


architecture. (These characteristics 
are shown in Figure 1.) 

In order to answer the question of 
which strategic bus architecture to 
choose, you must first rank the im¬ 
portance of these attributes. There is 
no universal “right” answer, how¬ 
ever. What is important to one com¬ 
pany or organization may not be 
important to others. In addition, pri¬ 
orities of a given company may 
change over time. Also, these priori¬ 
ties are certainly different for differ¬ 
ent application environments. 
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If affordability is at the top of your 
list, you would probably choose AT 
bus entry systems for short-term 
value. For longer-term value, 16-bit 
Micro Channel systems are the best 
choice because of their investment 
protection features. On the basis of 
overall technical merits, Micro 
Channel is the winner. 

In terms of IBM’s priorities, data in¬ 
tegrity was at the top of the list in 
developing Micro Channel architec¬ 
ture. Nothing is more important 
than data integrity in computer ar¬ 
chitecture. There was no room for 
compromise on this point. Compati¬ 
bility across multiple platforms for 
years to come was also well up the 
list. 

The best news is that Micro Chan¬ 
nel architecture has all the character¬ 
istics on the list in both current and 
future systems. Although Micro 
Channel expansion boards are not 
physically compatible with the origi¬ 
nal PC boards, they are compatible 
with the software developed for the 
IBM PC and AT. This compromise, 
while carrying its own cost, pro¬ 
vided a number of benefits related 
to all the other characteristics of an 
ideal architecture. 

Micro Channel architecture pro¬ 
vides a flexible, high-performance 
information transfer medium that 
can be implemented at low cost on 
personal systems. But it is also 
broad enough to be used by mid¬ 
range and mainframe computer 
products. The architecture incorpo¬ 
rates a flexible set of parameters 
that enhances its longevity by per¬ 
mitting a mixture of attachment de¬ 
vices that can operate at a wide 
variety of speeds. Its structure also 
minimizes the dependency on any 
single processor type or logic tech¬ 
nology. The flexibility of the specifi¬ 
cations also enables individual 


computer systems to be upgraded 
and enhanced. It is an open architec¬ 
ture that now has widespread accep¬ 
tance by the computer industry with 
more than 1,000 expansion boards 
available from nearly 400 compa¬ 
nies. Micro Channel architecture 
also provides better performance, 
reliability, and data integrity - im¬ 
portant attributes in today’s sophisti¬ 
cated multiuser and multitasking 
environments. 



In terms of IBM's 
priorities, data integrity 
was at the top of the list 
in developing Micro 
Channel architecture. 


The other bus architectures have 
some of these attributes. There are 
several good examples of systems 
based on NuBus, EISA, and AT ar¬ 
chitecture. But the benefits of Micro 
Channel architecture are much 
broader in their scope, affecting 
many more system implementa¬ 
tions, and delivering benefits to a 
much wider range of applications. 

Decisions, Decisions, 
Decisions 

To better understand how business 
factors influence the choice of bus 
architecture, let’s examine some typ¬ 
ical situations: 

Scenario 1: The Tick Tock Watch 
Company (a fictitious company) is 
under extreme cost constraints. It 
manufactures windup watches, hav¬ 
ing recently sold the quartz division 


to another company. Revenues are 
flat, and the company is in the pro¬ 
cess of reducing its number of em¬ 
ployees. It has decided to make 
DOS the strategic operating system 
for workstations for the next few 
years. It has a hodgepodge of XT 
and AT clones from a variety of 
manufacturers. The company has a 
small inventory of AT expansion 
boards and parts. 

Recommendations 

This company is in trouble. It proba¬ 
bly won’t be in business in two 
years because of its obsolete prod¬ 
uct line unless it can be transformed 
to a growth business. Obviously, its 
priorities begin and end with 
affordability. This is a clear-cut 
case for purchasing workstations 
based on the AT bus for several rea¬ 
sons. The existing board and parts 
inventory can be effectively used. 
The choice of DOS as the operating 
system and the absence of LANs 
are also factors. 

IBM has a competitive range of AT- 
bus systems for this company at an 
excellent entry price. Vendor selec¬ 
tion is an extremely important crite¬ 
rion. For any new system purchases, 
this company should focus on ven¬ 
dors such as IBM whose products 
have a high resale value and whose 
staying power in the business is se¬ 
cure. This will minimize both cost 
and risk as Tick Tock gets its 
“works" moving again. If the com¬ 
pany goes under in a couple of 
years, it will be selling all of its 
data processing assets. Another pos¬ 
sibility that should be investigated 
is leasing equipment instead of 
purchasing. 

Scenario 2: Med Tech, Inc. (a ficti¬ 
tious company) is a small growth 
company with rapidly increasing 
revenues whose primary business is 
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designing and manufacturing innova¬ 
tive medical diagnostic equipment. 
Most of the profits are reinvested 
for future growth rather than distrib¬ 
uted to stockholders. Its workstation 
strategy is to enable automation in 
every aspect of the business. Most 
of the employees are technical peo¬ 
ple who use their workstations for 
design and functional simulation of 
leading-edge equipment. The com¬ 
pany has high processing require¬ 
ments at the workstations. There are 
plans for numerous LAN servers in 
order to provide electronic mail ser¬ 
vices and shared graphical files of 
complex designs. 

Recommendations 

This is an easy one. This environ¬ 
ment can benefit immediately from 
standardizing on the Micro Channel 
bus. Selection of technical work¬ 
stations and servers from the RISC 
System/6000™ family for their 
UNIX applications is definitely rec¬ 
ommended for Med Tech. Addi¬ 
tional servers and workstations in 
the PS/2 system family or Micro 
Channel clones for business and of¬ 
fice applications are recommended. 
This company needs considerable 
processing power and capacity at all 
levels, and should standardize on 
386SX and higher Micro Channel 
platforms in order to run 32-bit ap¬ 
plications. It’s clear that perfor¬ 
mance and current and future 
compatibility are near the top of the 
list of priorities for its strategic bus 
architecture. 

Scenario 3: The two preceding sce¬ 
narios are, of course, quite atypical. 
Usually our choices are not so 
clearly defined. Our final scenario 
is more representative of organiza¬ 
tions today. 

SMI International (a fictitious com¬ 
pany) is a medium-sized company 


whose primary business is life and 
casualty insurance for United States 
servicemen and women. The 
company’s installed base of equip¬ 
ment includes a variety of systems 
based on the PC and AT bus. SMI 
is planning to implement a LAN 
strategy at the department level, but 
will continue to use its IBM main¬ 
frames as a central data repository. 
Over the next few years, SMI recog¬ 
nized that OS/2 has numerous bene¬ 
fits for its environment, but plans to 
continue using DOS as the primary 
operating system at its workstations 
for the near future. 

A strategic application for the future 
includes image processing to allevi¬ 
ate the vast amounts of paper han¬ 
dling and storage. In addition, a 
fully automated system using expert 
programs for policy issuance is 
planned. The automated system will 
require an easy-to-use graphical in¬ 
terface and will include a marketing 
presentation. 


Recommendations 

SMI International is on the verge of 
implementing some important appli¬ 
cations that will contribute enor¬ 
mously to productivity and 
profitability. This forward-thinking 
company is poised to gain a signifi¬ 
cant competitive advantage because 
of its plans for automation, net¬ 
works, and image processing. Re¬ 
duction in marketing and service 
expenses and paper-handling repre¬ 
sent enormous potential savings. 

SMI should select Micro Channel ar¬ 
chitecture for all purchases immedi¬ 
ately. Its strategic plans for LANs, 
OS/2, image processing and multi- 
media will be best served by Micro 
Channel systems. An economical 
choice for the workstation standard 
is a desktop 386SX system with a 
SCSI storage subsystem. The 
386SX microprocessor can run 32- 
bit OS/2 when it becomes available. 
The Micro Channel bus delivers 
high-performance image processing 
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through the use of bus masters like 
IBM’s Image Adapter/A. SMI’s 
image strategy would be comple¬ 
mented by the SCSI bus master be¬ 
cause almost all optical storage 
devices feature the SCSI interface. 

In addition, the systems can be up¬ 
graded using bus masters like the 
Aox MicroMASTER 486. 

For the automated policy issuance 
program, a good choice would be a 
more powerful Micro Channel sys¬ 
tem with a multimedia marketing 
presentation using Micro Channel 
products. The Audio Visual Connec¬ 
tion™ and a touch screen, and an 
image capture system with a remov¬ 
able SCSI read/write optical storage 
device are recommended for this ap¬ 
plication. This combination can be 
used to capture and store a photo¬ 
graph of the applicant, hand-written 
information, and the applicant’s sig¬ 
nature. A policy and wallet card 
could be issued at the time of appli¬ 
cation and put in force, pending ver¬ 
ification of the applicant’s motor 
vehicle or medical records and 
credit card information. 

Micro Channel personal systems are 
a good choice for personnel en¬ 
gaged in actuarial research at SMI 
because of their ability to accommo¬ 
date compute-intensive and data 
base “engines” like the i860™ Wiz¬ 
ard adapter. Another excellent 
choice would be a Micro Channel 
technical workstation like one of the 
IBM RISC/System 6000 
POWERstations. 

A logical choice for the departmen¬ 
tal LAN servers are 32-bit Micro 
Channel systems like the IBM PS/2 
Model 95 XP 486 systems running 
OS/2. These I/O-intensive applica¬ 
tions in a multitasking environment 
are a perfect fit for the performance 
and data integrity features of Micro 
Channel systems. 


For existing inventory of AT-bus 
systems, there are a number of alter¬ 
natives, including downgrading sys¬ 
tems to less sophisticated 
applications. What this company 
should not do, however, is to post¬ 
pone implementation plans for their 
strategic applications because of 
their existing inventory of AT-bus 
systems. The cost savings and pro¬ 
ductivity increases for the image 
processing system and automated 
policy issuance program will 
quickly pay for the additional equip¬ 
ment costs. 

Bus Strategies 

Let’s look at three bus strategies 
and how they might fit in your orga¬ 
nization. These are the choices: 

1. Continue to invest in AT-bus sys¬ 
tems for the foreseeable future. 

2. Maintain both AT and Micro 
Channel bus architectures. 

3. Make the transition as rapidly as 
possible to Micro Channel architec¬ 
ture systems. 

The AT-Bus Strategy: The tradi¬ 
tional PC/XT/AT bus does not use 
the full capabilities of 386 and 486 
architecture and does not accommo¬ 
date any 32-bit I/O devices. Under 
what conditions would you choose 
this bus? If your only uses now and 
in the future are DOS personal pro¬ 
ductivity applications, this bus strat¬ 
egy makes sense. This is especially 
true if you are willing to trade off a 
shorter equipment life for a lower 
initial price. 

Stand-alone systems with limited 
performance requirements and sin¬ 
gle-tasking applications do not ex¬ 
ploit the full potential of Micro 
Channel architecture. In addition, 
the inability to upgrade these sys¬ 
tems with additional processing 


power dictates a strategy based on 
approximately a 2-3 year equipment 
life. This strategy may suit your re¬ 
quirements quite well in the near 
term. 

In the longer term, however, this 16- 
bit strategy will necessarily give 
way to a 32-bit I/O bus, just as the 
8-bit PC bus yielded to the 16-bit 
AT bus when the price/performance 
ratio became attractive enough. 

A Two-Bus Strategy: For many 
purposes, a two-bus strategy using 
both AT and Micro Channel sys¬ 
tems is a viable approach for the 
near future. The AT bus is adequate 
for 286 and 386SX systems for 
DOS applications in a stand-alone 
environment or as DOS network re¬ 
questers with moderate performance 
requirements. It is also a good 
choice for laptop systems because 
of their limited expandability, 
shorter equipment life, and rapidly 
changing display technology. If this 
two-bus strategy is your choice. 
Micro Channel systems are appropri¬ 
ate selections for servers and for 
those users who require higher per¬ 
formance than the 386SX systems 
can deliver, especially for OS/2 or 
UNIX applications. 

This two-bus approach is a good in¬ 
terim strategy, but is not viable in 
the long term. Processor power will 
continue to come down the cost 
curve, and a 32-bit I/O bus will be 
required to effectively utilize it. It is 
only a matter of time, however, 
until this strategy will give way to 
systems with a 32-bit I/O bus. 

The Micro Channel Standard: 

There are benefits in having a sin¬ 
gle bus strategy in most environ¬ 
ments. Even though few boards are 
moved from system to system, in¬ 
ventory management and purchas¬ 
ing power are important benefits of 
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a single bus strategy. Another bene¬ 
fit lies in the reduction of support 
and software requirements. Multiple 
bus strategies can add unnecessary 
complexity in setup, service, and 
software requirements. 

One of the advantages of Micro 
Channel architecture that adds value 
to managing the transition to the 32- 
bit environment is its 16-bit system 
and expansion board implementa¬ 
tions. Because 16-bit systems and 
boards that utilize almost all of the 
advanced features of this architec¬ 
ture can be built, this brings value 
to a large number of end users. 

A sensible transition plan, therefore, 
can be based on Micro Channel 
386SX systems. This effectively po¬ 
sitions you for the 32-bit future 
without immediately paying the 
price for the higher function. It also 
provides a good base upon which to 
build future applications like image 
processing and multimedia. Many 
16-bit Micro Channel boards offer 
throughput that approaches that of 
32-bit boards in some applications. 
Many advanced function boards 
available today are 16-bit 
implementations. 

You should plan on the 386SX mi¬ 
croprocessors being around for 
awhile. Faster chips and integrated 
functions will prolong their lives. 

So a near-term investment in 16-bit 
Micro Channel systems and boards 
is a good plan. 

Micro Channel expansion boards 
are at the beginning of their useful 
life rather than near obsolescence. 
All Micro Channel boards have 
been designed and built since 1987 
using modem electronics and VLSI 
circuitry. Many boards built for the 
AT bus were designed and built 
years ago with older, slower compo¬ 


nents that may reduce performance 
in newer systems. 

Transition Planning 

At this point, you are probably con¬ 
vinced that Micro Channel architec¬ 
ture represents the best choice of 
microcomputer bus architecture for 
the future. However, what is a sensi¬ 
ble transition plan? Many compa¬ 
nies have large inventories of AT 
boards and AT bus machines. Intro¬ 
ducing a different bus architecture 
into this environment complicates 
inventory management and end-user 
support. Standardizing with Micro 
Channel systems, with a strategy of 
migration over time, requires some 
careful planning. 

Some appropriate steps are: 

1. New purchases should be limited 
to Micro Channel systems. If this 
isn’t feasible, a good place to start 
is with users having high-perfor¬ 
mance requirements and for server 


applications. Establish Micro Chan¬ 
nel systems as the workstation stan¬ 
dard as soon as possible, using 
economical 386SX systems initially. 

2. Identify key applications that ef¬ 
fectively utilize the value of Micro 
Channel architecture solutions. 
Image processing, multimedia, com¬ 
pute-intensive, and server applica¬ 
tions are excellent showcases for 
Micro Channel systems because of 
their dramatic cost savings and pro¬ 
ductivity improvements. 

3. Develop a used-equipment plan 
for older systems. The time-honored 
method is to downgrade these sys¬ 
tems to other users. This is still the 
best plan if it doesn’t interfere with 
implementing key applications in 
your organization. Other alterna¬ 
tives are trading for new systems, 
selling the inventory, or donating to 
nonprofit organizations. Discuss 
these options with your accounting 
department. 
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A New Paradigm 

Introducing Micro Channel systems 
to new users requires a new para¬ 
digm for performance. Most people 
think of performance in terms of 
raw CPU power: in order to get bet¬ 
ter performance, you need a new 
system with a faster CPU. For sys¬ 
tems based on Micro Channel archi¬ 
tecture with its multimaster 
capabilities, a paradigm of distrib¬ 
uted processing is required: perfor¬ 
mance benefits are derived from 
expansion boards. In other words, 
high-performance, application- 
specific bus masters can deliver ad¬ 
ditional power to existing systems. 

While this may not be quite as excit¬ 
ing as a new system, it is far more 
cost-effective and versatile (al¬ 
though it’s hard to imagine people 
bragging about their new adapter!). 

In years to come, entire computers 
will reside solely on expansion 
boards. 

Look to Tomorrow 

Having a vision of the future is im¬ 
portant in today’s confusing environ¬ 
ment. Knowing where you want to 
go is the first step to getting there. 
Managing transition in a changing 
environment is, perhaps, the most 
challenging of all tasks. Making the 
right decisions now and planning 
for the future are the tasks at hand. 
One thing is sure: a high-perfor¬ 
mance multitasking bus architecture 
is an absolute requirement for the 
workstations of the ’90s. 
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The Network Is 
the Message 

Chet Heath 
IBM Corporation 
Boca Raton , Florida 

This description of a concept 
called “workgroup computing” is 
reprinted from the recently pub¬ 
lished book The Micro Channel Ar¬ 
chitecture Handbook by Chet 
Heath and Winn L. Rosch. Infor¬ 
mation about the book follows the 
article. 

A Busmaster Example 

Not unlike the manner in which tele¬ 
vision allowed thought to be trans¬ 
mitted and converted rapidly into 
popular understanding as entertain¬ 
ment, a new medium has invaded 



the workplace - this time to effi¬ 
ciently allow us to coordinate our ef¬ 
fort and direction when groups 
work toward common goals. Not in¬ 
sidiously, but silently, we absorbed 
the new philosophy by an evolution¬ 
ary adaptation of our daily work 
habits. This “Trojan horse” of tech¬ 
nology is the workgroup system. Its 
soldiers are made of software and 
silicon, and more than ever, they 
will free men to think rather than 
work. 

When personal computers were first 
accepted in the workplace, they 
were perceived and promoted as in¬ 
dividual tools (sometimes toys) of 



productivity. They followed “dumb” 
terminals that were dependent upon 
the vitality of distant resources, by 
providing the individual means re¬ 
quired to accomplish routine 
desktop drudgery fully under the 
control, and sight, of the user. Be¬ 
yond that, they did not imply large 
investment and could be justified by 
the improved productivity of the in¬ 
dividual working alone. Simple indi¬ 
vidual tasks, such as composition of 
a letter, filing, or income tax prepa¬ 
ration, justified the systems in the 
workplace and occasionally in the 
home. Perhaps most of all, the abil¬ 
ity to reduce complex, numerically 
based decisions by way of the 
spreadsheet program cemented the 
PC into the workplace. 

The isolated desktop could be made 
to exchange information within a 
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group or office by physically ex¬ 
changing the storage medium, the 
diskette. The inexpensive incorpora¬ 
tion of the hard disk, with an initial 
capacity of 30 diskettes, led to local 
manipulation of information larger 
than the capacity of a single disk¬ 
ette. Further, the desire to control in¬ 
formation located in the distant 
systems and to interact with that 
data led to a need to communicate 
in real time. The first connection 
was to the very same distant re¬ 
sources from which the desktop had 
earlier declared independence. But 
then, more slowly, it spread be¬ 
tween the desktops, as workers be¬ 
came more dependent upon the 
output of their peers than on the dis¬ 
tant resource. 

The workers needed to network lo¬ 
cally, much as medieval knights had 
in “round tables” centuries before 
them, or, as in more recent times, 
workers had convened around the 
water cooler. The success of the 
local area network, or LAN connec¬ 
tivity, between the electronic 
desktop systems is, therefore, a 
strong statement about the need of 
the modem knights of the desktop 


to band together to achieve common 
goals. 

Why, if humans tend to herd to¬ 
gether, are not personal systems 
initially designed as integrated work¬ 
group systems rather than stand¬ 
alone boxes? It is because, like 
many inventions before it, the per¬ 
sonal computer had to develop an in¬ 
dividual following before it could 
be integrated into society. Airplanes 
preceded airports and airlines, elec¬ 
tric lights glowed from batteries 
before power stations were estab¬ 
lished, and Bell spoke one-on-one 
with Watson long before the switch¬ 
board came along. Of course today 
air travel, electric light, and the tele¬ 
phone are integrated into vast stan¬ 
dardized networks, and the design 
of the instrument at the user inter¬ 
face assumes that. 

Until now, no personal system had 
been designed specifically to allow 
the desktops to collectively assem¬ 
ble into one force. The connectivity 
that allows users to congregate in a 
common network has so far been 
added as an “afterthought” periph¬ 
eral attachment to stand-alone de¬ 
signs. The attachment was either 


through a bus-attached card, or sim¬ 
ilar logic on a system board, or out¬ 
board of the system entirely, 
through a peripheral port. It is now 
time for the personal system to inte¬ 
grate the interconnectivity of the net¬ 
work into its basic design. PS/2 
systems with Micro Channel archi¬ 
tecture have done exactly that. 

When Micro Channel personal sys¬ 
tems were first announced, it was 
stated that much of the new concept 
was very subtle in nature. One com¬ 
ponent, peer-to-peer bus master 
communication, was an element of 
that subtlety. Ironically, peer-to-peer 
implies interaction between individu¬ 
als, like Bell and Watson, yet it is 
the building block of 
intercommunication. 

Consider the following design con¬ 
cept, first publicly shown by IBM at 
the Computer Dealers Exposition 
(COMDEX®) in Las Vegas, in the 
fall of 1989. It is not a product, but 
it could be, and it depends heavily 
on the foundation laid in place 
within PS/2 systems that implement 
standardized Micro Channel inter¬ 
faces. It should not be inferred that 
IBM has any plans to market such a 



Figure 1. The GUESS Card 
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system; it is shown here merely as 
the author’s example of the flexibil¬ 
ity of Micro Channel architecture. 

During the initial definition of the 
Micro Channel interface, the author 
had envisioned six conceptual tests 
of the extendability of the personal 
system. In one, the basic computer 
and its associated subsystem sup¬ 
port components (such as interrupt 
controller, time-of-day clock, and 
system timer) would be assembled 
along with sufficient memory to 
contain an operating system and ap¬ 
plications on a single card (Figure 
1). Also resident on the card is the 
basic user interface of keyboard, 
mouse, VGA (or better) display. 


and compatible diagnostic ports, to 
make the “system on a card” 
serviceable. 

The basic user interface is available 
from standard connectors on the 
rear bracket to the existing VGA, 
keyboard and pointing devices. It 
has been shown elsewhere that 
these interfaces can be propagated 
hundreds of feet. 

As a bus master, this card could 
form the compatible heart of a sys¬ 
tem, requiring only the addition of 
disk, diskette, connectivity and 
printer interface on a system 
“Combo” board with power supply 


and cabinet for completion as in 
Figure 2. 

This, in itself, is an exciting con¬ 
cept, but only begins the possibili¬ 
ties of such a design point. In a 
sense, the card is a system, less all 
the previously mentioned elements. 
To software, it forms a Generic 
User Environment of a Small Sys¬ 
tem (GUESS). 

Now plug a number of such 
GUESS cards into any PS/2 system 
with Micro Channel architecture to 
form a cluster of users in close prox¬ 
imity, as in Figure 3. 



Display 


Keyboard 






Mouse 



Figure 2. A Small “Entry” System Based on a GUESS Card 
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User #4 


User #5 


Figure 3. Cluster Host with Four GUESS cards 


Because the cards are bus masters, 
and because the Micro Channel de¬ 
fines public memory on the bus or 
peripheral, each GUESS card can 
read from or write to memory lo¬ 
cated in the system or on other 
cards, even on other GUESS cards. 
The last property is called peer-to- 
peer bus master operation on the 
Micro Channel. 

The concept could be made to work 
in a limited way for AT-based sys¬ 
tems without peer-to-peer bus mas¬ 
ter communication. In such a 
system, a common system resource 
is assigned all data transfer responsi¬ 


bility, and the number of peripher¬ 
ally attached users becomes limited 
by the performance of that element. 
The central system resource is often 
the processor, and it already has 
enough to do. Dependence on a cen¬ 
tral resource is “designed-in” obso¬ 
lescence, as the performance and 
number of users is limited by the 
collective load on the central re¬ 
source, which is fixed in capacity at 
time of purchase. 

The cluster host LAN does not have 
this defect. The GUESS card need 
only support its own data transfer 
requirements. 


As each GUESS card is added, the 
processor power to support its user 
is added to the system, and the con¬ 
nectivity to communicate is added 
as well. Micro Channel architecture 
and GUESS work together to main¬ 
tain the user’s asset in system unit 
and peripherals. 

In theory, an operating system 
could be defined to coordinate ac¬ 
cess to common system elements, 
such as disk, printer, communica¬ 
tion connectivity, and even bridge 
to external LAN. Such an operating 
system is a monumental task if 
taken as an isolated effort. Fortu- 
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Figure 4. Conventional LAN Topology 


nately, there is an existing founda¬ 
tion to build on. Because Micro 
Channel multimaster arbitration 
uniquely grants the bus to one 
owner at a time, and because that 
owner is “publicly” declared on the 
arbitration bus, and again because 
of the public addressing of I/O, the 
Micro Channel interface can emu¬ 
late a token ring LAN where the 
bus grant is the “token” and the bus 
address is the client or server 
address. 

Further, peer-to-peer communica¬ 
tion is a principal advantage of 
token ring over host connectivity be¬ 
cause only one block transfer on the 
bus is required per message. Peer-to- 
peer communication and coordina¬ 
tion of multiple processors and 
subsystems is the domain of a con¬ 
trol block architecture, such as 
Micro Channel’s Subsystem Control 
Block (SCB) architecture. Provision 
for resource allocation, error detec¬ 
tion and recovery, and diagnostic 
isolation of the processors is the do¬ 
main of Micro Channel Program Op¬ 
tion Select (POS), Parity, and 


Channel Check protocols. Net: 

This concept “needs” PS/2’s Micro 
Channel architecture. 

The cluster host-attached peripher¬ 
als, disk, diskette, LAN bridge, con¬ 
nectivity, and print adapters are 
then “served” to the GUESS card’s 
attached users by modifications of 
standard local-area-network control 
programs. The cluster host “sees” 
each GUESS card as a user on a net¬ 
work, and each GUESS card “sees” 
the cluster host as the server. 

GUESS cards relate to each other as 
peer clients in the network. The re¬ 
sulting system is not diskless, be¬ 
cause a portion of the system disk 
can be allocated to each user; how¬ 
ever, the user interface is diskette¬ 
less. The placement of the disk and 
diskette at a point physically re¬ 
moved from the user has security 
and environmental advantages and 
is actually desirable in many 
applications. 

The utilization of the peripherals is 
no higher than that of a small LAN 
of eight users or less. The bus traf¬ 


fic may be reduced over a compara¬ 
ble LAN as the cards could use one 
transfer to communicate peer-to- 
peer with SCB-designated peripher¬ 
als. A conventional server system 
would need at least two, and per¬ 
haps four, transfers with system 
memory and the microprocessor in 
order to move the same data. The 
network control program is helped 
by the SCB architecture by delegat¬ 
ing part of its function out to the 
cards. 

The Micro Channel interface has a 
default burst data transfer rate of 20 
million bytes per second. As a local 
area network serial interface, that is 
equivalent to 160 megabits per sec¬ 
ond or 10 times present token ring 
network speeds. Net: Actual perfor¬ 
mance should exceed that of a com¬ 
parable small LAN. 

Consider the impact on the user and 
system owner of such a configura¬ 
tion. In a conventional LAN topol¬ 
ogy, as in Figure 4, the server and 
clients each have many duplicated 
functions. Many of these functions 
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Net Savings 

• Frames 

• Covers 

• Power Supply 

• LAN Attachment 

• Channel Support Logic 

• System Board and Connectors 


To Remainder of Network 


Figure 5. Cluster Host LAN Topology 



do not contribute to data movement 
or, like the diskette or client LAN 
card, have very low utilization in 
normal operation. 

In a cluster of GUESS cards, each 
user is supported by a card rather 
than a system unit. In effect, the 
card plugs into a server, as in 
Figure 5. 

Because all of the basic I/O func¬ 
tions are provided by the “cluster 
host” system, the user has the basic 


function of the desktop system less 
the cost of frames, covers, local 
disk and diskette, local area net¬ 
work card, and much of the system 
board logic required to build a con¬ 
ventional system. These elements 
can be a majority of the cost in a 
system. Net: The per-user cost of 
attachment should be less than a 
comparable conventional LAN 
design. 

Furthermore, because the GUESS- 
connected users share the system pe¬ 


ripherals, the cost of those peripher¬ 
als is “amortized” over all the users, 
and the cost of the system is 
thereby reduced additionally. There¬ 
fore, a centralized SCSI file system 
can outperform the lower-cost file 
systems of small desktop systems, 
yet the cost per user “seat” in the 
system is less than eight such small 
disk systems. 

An optical “FDDI” LAN, as in Fig¬ 
ure 6, may be prohibitively expen¬ 
sive if connected to each client in a 



Figure 6. Fourteen-User System with Optical LAN abs Dual SCSI File Systems 
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conventional LAN topology. It 
would cost as little as one seventh 
as much per user if added as part of 
the cluster host system. A similar 
scenario exists for the incorporation 
of a centralized numeric processor, 
like IBM’s i860-based Wizard card 
in the cluster host. 

The concept is flexible. It is be¬ 
lieved that the GUESS card can em¬ 
ulate an “X-Window” with a real 
processor instead of a virtual one. 
The real processor stores applica¬ 
tions in slower, less expensive 
RAM on the GUESS card, rather 
than the high-speed RAM of the 
central AIX system. In the configu¬ 
ration shown at COMDEX, a 7437 
small, 370-based Micro Channel 
product ran VM (SP5). It provided 
PROFS® mainframe host 3279-like 
attachment across the Micro Chan¬ 
nel via a “virtual” 3274 control unit 
emulated in software, with virtual 
TCA and DCA cards as mailbox 
windows in the system RAM of a 
cluster host PS/2 Model 80. The in¬ 
terface to users was the familiar 
“hot key” between host VM applica¬ 
tions and DOS on the GUESS card. 
No external dependency on a main¬ 
frame was required for basic opera¬ 
tion (however, such connectivity 
was not designed out, either). Net: 
The per-user cost of entire systems 
may be further reduced over a con¬ 
ventional LAN or host attachment 
configurations . 

The client’s power supply, LAN 
attach card, LAN wiring, the multi¬ 
plexing address units of conven¬ 
tional LANs, and the mechanical 
disk and diskette systems are major 
contributors to the failure rate of 
LAN-connected personal computers 
of any bus design. The elimination 
of these elements from the GUESS 
card improves the reliability of the 
user interface several fold. The 
availability of each server to the 


conventional network is dependent 
on the server’s power supply and 
file system. The same is true for the 
cluster host design. An uninterrupti¬ 
ble power supply will protect the 
server in a conventional LAN; with 
cluster host, it protects the clustered 
clients as well. Because the clients 
draw the power of a card rather 
than that of a system, up to 90 per¬ 
cent of the electric power per client 
can be conserved. It is therefore eco¬ 
nomical to provide such protection. 
Net: The reliability of a cluster 
host-based LAN can, in theory, ex¬ 
ceed that of a conventional LAN to¬ 
pology. 

In a conventional LAN, a client can 
be brought off-line for service with¬ 
out interrupting the availability of 
the system to other clients. One 
shortcoming of the cluster host 
LAN is that the entire cluster must 
be powered down to service a 
GUESS card, interrupting a system 
in continuous operation. Modern 
component reliability can reduce the 
probability of such an interruption 
of availability to a rare occurrence. 
This loss of availability during ser¬ 
vice operations is not a concern 
when service can be scheduled for 
idle periods. Inoperative stations 
can be cycled off-line by POS while 
awaiting service. 

The potential exists for the GUESS 
card to assume the system’s duties 
and control peripheral adapters and 
memory much as the system would, 
albeit at degraded performance lev¬ 
els, because the GUESS card is a 
master and a system on the bus as 
well. Such operation could conceiv¬ 
ably be invoked manually or per¬ 
haps with very complex software 
automatically. Net: Availability can 
be made equivalent to conventional 
LANs in most scenarios . 


Another consideration with the clus¬ 
ter host LAN is the cost of wiring. 
Where a facility has been wired for 
token ring, that wiring can be used 
to interconnect clusters rather than 
individual users in the conventional 
LAN. This provides up to an eight- 
to-one cost effectiveness for exist¬ 
ing wiring with the cluster host 
LAN. Due to the limitation in cable 
length from the cluster host, if users 
are spaced at a distance greater than 
a few hundred feet from the cluster, 
it may be advantageous to bridge to 
token ring for that set of users. 
Where users are clustered in close 
proximity, like in many service in¬ 
dustries, the cluster host LAN topol¬ 
ogy is advantageous. One hybrid 
configuration is achieved when a 
desktop system is shared between 
two adjacent workspaces, as in 
Figure 7. 

The system, with diskette and pe¬ 
ripheral devices, is at the left hand 
of one user and the right hand of an¬ 
other. The same hybrid might ap¬ 
pear as a two-user transportable 
system with a GUESS card installed 
in a P70 system. 

Potentially, bridging to conventional 
LAN has other advantages. Only 
the transfers that “escape” the clus¬ 
ter appear on the LAN. Local de¬ 
partmental traffic need not occupy 
or burden the network. Only one 
token ring address may need to be 
consumed per cluster, potentially 
raising the total number of stations 
on the LAN to 1024, rather than the 
normal limit of 256. When systems 
initially load programs to the disk¬ 
less stations on power-up, the clus¬ 
ter host LAN can transfer a full 
16-megabyte system memory load 
theoretically in a fraction of the 
time of conventional token ring 
LAN. 
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Figure 7. Hybrid Two-User System 


The concept is highly dependent 
upon characteristics of the Micro 
Channel interface. Fully 85 percent 
of the system can be purchased 
today in the form of high-end PS/2 
systems, with the advantages of the 
approach being derived from the 
dual use of the Micro Channel inter¬ 
face as an ultra-high-speed data 
transmission path, as well as the pe¬ 
ripheral attachment means. Yet, 
much work lies between concept 
and reality with this new approach 
to workgroup systems. New LAN 
control programs, new hardware 
packaging, BIOS, diagnostics and 
Power On Self-Test procedures 
must be designed. New means of 
bridging to conventional LANs 
must be defined. It is even possible 
that an insurmountable obstacle 
may be discovered that prevents im¬ 
plementation of the concept alto¬ 
gether. Yet with IBM’s open 
disclosure of the concept to the in¬ 
dustry, there will be many who are 
attracted to the challenge. 

Where the conventional LAN is still 
implemented with stand-alone sys¬ 
tem designs, the external connectiv¬ 
ity adds to both the cost and failure 


rate of the system. The serial LAN 
data throughput acts as a limiter to 
performance of the distributed 
intelligence. 

Alternately, the integration of the 
workgroup computer designs out 
the limitations of conventional 
LANs, and does for the group what 
the PC did for individuals: it gives 
them autonomy. The next logical 
step is the integrated workgroup 
computer, where “the network is the 
Micro Channel.” 
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One of the most frequently asked 
OS/2 questions is “How do I make 
my printer print a job using land¬ 
scape orientation?” The truth is, 
using a printer’s specialized fea¬ 
tures for selected output is quite 
easy. A single Presentation Man¬ 
ager call added to your applica¬ 
tion enables you to select any 
combination of a printer’s fea¬ 
tures for output by invoking the 
Print Manager’s Job Properties. 
This article describes how to use 
the PM DevPostDeviceModes call 
to invoke Job Properties. 

When data is sent to the Print Man¬ 
ager, there are two sets of variables, 
or properties, that determine exactly 
how the data is printed. 

The primary set of variables, called 
Printer Properties, is established 
when the printer driver is added to 
the Print Manager. The actual 
Printer Properties vary with each 
printer driver but usually define op¬ 
tional printer hardware, size and 
type of papers, fonts, supported 
codepages, print quality, paper ori¬ 
entation, paper tray selection and 
spooler filter type. 

The Printer Properties for a printer 
driver apply to all printing directed 
to that driver. A subset of these vari¬ 
ables can be changed for each print 
job allowing for variations in output 
appearance. These variables are 
called Job Properties. 

An application can support the set¬ 
ting of Job Properties through the 
use of the DevPostDeviceModes 


(WDPDM) Device Function call. 
The use of this call causes a Job 
Properties dialog box to be dis¬ 
played, allowing you to select the 
desired properties for the current 
print job. 

To add Job Property selection to 
your application’s print routine, 
issue the DevPostDeviceModes 
(WDPDM) call with the 
DPDM-POSTJOBPROP option 
prior to opening the Print Manager. 


The DevPostDeviceModes call must 
be issued twice. First, with a null 
pointer as parameter two, to obtain 
the size of the Driver Data struc¬ 
ture. This structure can range in size 
from 50 to 700 bytes depending 
upon the printer driver. Figure 1 
shows how to code the first 
DevPostDeviceModes call in 
COBOL. For C programs, see the 
Presentation Manager Program¬ 
ming Reference, Volume 1 
(64F0276). 


CALL "WDPDM” using hab, 

NULL, 

DrvrLength, 
DrvrName, 
PrtLength, 

PrtName, 

NULL, 

NULL, 

DPDM-POSTJOBPROP, 
StructureSize. 


Figure 1. Call to Determine Driver Data Structure Size 
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Upon return, StructureSize contains 
the length of the required data struc¬ 
ture DEVSTRUCT-DRIVERDATA. 
Following the creation of the 
DEVSTRUCT-DRIVERDATA 
structure, of the size returned in 
StructureSize, reissue the 
DevPostDeviceModes call 
(WDPDM) with the 
DEVSTRUCT-DRIVERDATA 
pointer as parameter two. {Note: 
COBOL programs must use the 
WinCreateDataStructure (WUCDS) 
call to create the necessary data 
structures.) This causes the Job 
Properties’ dialog for the specified 
printer driver to appear, allowing 
the user to select the desired proper¬ 
ties. The driver then returns the up¬ 
dated driver data structure to your 


program. Figure 2 shows how to 
code the second 
DevPostDeviceModes call in 
COBOL. 

The content and format of these 
structures varies with each printer 
and their formats have not been ex¬ 
ternalized. However, it is not neces¬ 
sary that your program examine the 
structure. Simply pass the entire 
structure, as part of the SplQmOpen 
(SMOPEN) or DevOpenDC 
(WDOPEN) call used to open the 
Print Manager. Figure 3 shows how 
to code the SplQmOpen call in 
COBOL. For C programs, see the 
Presentation Manager Program¬ 
ming Reference , Volume 1. 


CALL "WDPDM" using hab, 

DEVSTRUCT-DRIVER. 
DrvrLength, 
DrvrName, 
PrtLength. 
PrtName, 

NULL. 

NULL. 

DPDM-POSTJOBPROP, 
StructureSize. 


Figure 2. Call to Invoke Job Properties Dialog 


CALL "SMOPEN" using LengthTokenID. 

TokenID. 

LengthDataStructure, 
DevOpenStruct. 
hSPL. 


Figure 3. Call to Open Spool File 


With the SplQmOpen call, the 
TokenID is coded as a single 
character and the 
LengthTokenID is defined as 1. The 
LengthDataStructure defines the 
number of entries specified in the 
DevOpenStruct. The last parameter, 
hSPL, is the handle of the open 
spool entry returned by this call. 

The DevOpenStruct is defined in 
the individual language bindings ref¬ 
erence manuals or the Presentation 
Manager Programming Reference , 
Volume 1. 

Use of the DevPostDeviceModes 
call offers users extensive flexibility 
in how output is printed. Yet it does 
not require complex application 
code to support unique printer 
features. 
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Comparing 
PC-DOS, OS/2, 
and AIX PS/2 

Craig Chambers 
IBM Corporation 
Dallas, Texas 

This article examines and com¬ 
pares the AIX PS/2, PC-DOS, and 
OS/2 operating systems. The capa¬ 
bilities, similarities, and differ¬ 
ences of these three systems are 
clarified so you can properly posi¬ 
tion them in your installation. 

Today, many personal computer 
users are reaching the limits of the 
PC-DOS operating system and are 
facing the decision of how to up¬ 
grade their systems. Users are trying 
to decide whether to upgrade to 
OS/2, UNIX, or AIX. This article 
compares the PC-DOS, OS/2 Stan¬ 
dard Edition, and AIX PS/2 operat¬ 
ing systems to help these DOS users 
make their upgrade decision. Re¬ 
cently released windowing products, 
such as Microsoft Windows Version 
3 and AlXwindows™, may have a 
significant impact on this decision 
and are discussed as well. 

This is written for DOS users. Read¬ 
ers should be familiar with comput¬ 
ers, PC-DOS, how disk drives are 
organized (tracks and sectors), the 
differences between ROM and 
RAM, and similar fundamental con¬ 
cepts. This perspective will be used 
to explain how OS/2 and AIX com¬ 
pare and contrast with DOS. The 


various graphical user interfaces of 
each system are also examined. 

AIX is IBM’s enhanced version of 
UNIX. The AIX version discussed 
in this article is for the PS/2. Com¬ 
ments about AIX will generally 
apply to UNIX as well. 

What is an Operating 

System? 

A computer is a collection of hard¬ 
ware that by itself can do nothing. 
Before a computer can perform use¬ 
ful work, it must have a program 
called an operating system installed. 


This situation is similar to an auto¬ 
mobile. Without gasoline, it will not 
run. The operating system “fuels” 
the computer and has three basic 
functions, which are: 

• Organizing data into a file sys¬ 
tem so it can be used by programs 

• Loading and executing programs 

• Allowing programs to use the de¬ 
vices attached to the system 

The faster and more powerful the 
car, the better the grade of gasoline 
it needs. The same is true with com¬ 
puters. Small computers can make 
do with a simple operating system. 
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As computer hardware gets more 
powerful, then the operating system 
must be equally powerful. 

Entry-Level Systems 

DOS (both PC-DOS and the similar 
MS-DOS®) is the most widely used 
computer operating system in the 
world today. It is installed on more 
than 40 million personal computers. 
For simplicity, PC-DOS and MS- 
DOS will be referred to as simply 
DOS. 

DOS became available in 1981 with 
the release of the Intel 8088-based 
IBM Personal Computer (PC). The 
first DOS version required just 16 
KB of RAM and was designed to 
run with just 64 KB of RAM and a 
single 160 KB floppy disk drive. 
Then, a personal computer with 64 
KB of RAM was a large system, so 
the 1 MB 8088/DOS address space 
was extremely generous. DOS is 
based conceptually on the older 
8-bit CP/M system and provided a 
similar set of commands, command 
prompt, and function set. 

DOS was originally written for 
small 8088 microcomputer-based 
systems. It was designed to run just 
one program at a time and to be 
used by one person at a time. Be¬ 
cause of this, it does not contain 
functions for data security, data shar¬ 
ing, performance monitoring, and so 
forth. 

Over time, as the capability of the 
personal computer hardware in¬ 
creased and hardware prices 
dropped, the power of the personal 
computer system increased many 
times. With this increase in power 
came many more powerful applica¬ 
tion programs. In fact, a new type 
of program, known as the terminate- 
and-stay-resident (TSR) or pop-up, 
became available. 


These programs get around the 
DOS limitation of allowing just a 
single program to be active at one 
time. By taking control of the hard¬ 
ware timer and keyboard, these pro¬ 
grams can perform a certain level of 
multitasking. In fact, the DOS 
PRINT command takes advantage 
of this ability. 

By the late 1980s, personal comput¬ 
ers based on the newer Intel 
80286™, 80386™, and 80486™ micro¬ 
processors were equipped with as 
much as 16 MB of RAM and con¬ 
tained hard disk drives with capaci¬ 
ties of several hundred megabytes. 
The number of TSRs had multiplied 
to the extent that they were very dif¬ 
ficult to manage and used a substan¬ 
tial portion of the DOS 1 MB 
address space. 

Although the system had as much 
as 16 MB of RAM, DOS could 
only use 1 MB of it, because it was 
still designed for the 8086 proces¬ 
sor. With the release of Version 
4.00, DOS included support for “ex¬ 
panded memory.” While this new 
type of memory simplifies writing 
for large programs, it does not elimi¬ 
nate the need for application pro¬ 
grammers to code elaborate routines 
to use the extra system memory. 
Without this support, many applica¬ 
tions no longer fit into the 1 MB 
area after the device drivers and 
TSRs are loaded. 

Another enhancement introduced 
with DOS 4.00 was support for hard 
files with capacities greater than 
32 MB. 

One major advantage of DOS is the 
large number of programs written 
for it. As a result, DOS connects to 
most other systems and the applica¬ 
tions generally have very polished 
user interfaces. 


Advanced Systems Become 
Available 

The limitations of DOS are re¬ 
moved by OS/2, the operating sys¬ 
tem announced in 1987. OS/2 uses 
the same commands, has the same 
basic system structure, and is a logi¬ 
cal follow-on to DOS. OS/2 is so 
compatible with DOS that most 
DOS programs can be run un¬ 
changed in one of the OS/2 ses¬ 
sions, called the DOS compatibility 
box. 

DOS is designed to operate on the 
8086/8088 processor family that 
runs in a system processor state 
known as real mode. In real mode, 
applications have total control of 
the system and assume that no other 
programs are executing while they 
are running. Therefore, these appli¬ 
cations can completely take over the 
system hardware. 

Real mode is the only mode sup¬ 
ported by the 8086/8088 and com¬ 
patible system processors. It was 
not named until Intel released the 
80286 processor, which contains a 
more powerful mode of operation 
called protected mode. 

In protected mode, special hardware 
in the microprocessor separates ap¬ 
plications, making them unaware 
that other programs are active. If a 
program tries to access another 
program’s memory or hardware de¬ 
vices, the operating system can 
catch it and terminate the program, 
thereby preventing a system crash. 
Protected mode allows access to the 
full 16 MB of RAM that can be in¬ 
stalled in systems based on 80286 
(and later) microprocessors. 

OS/2 and AIX PS/2 operate in pro¬ 
tected mode. OS/2 and AIX pro¬ 
grams use the full amount of 
memory installed in the system. 
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This eliminates the complexities of 
dealing with “regular” memory, ex¬ 
tended memory, and expanded mem¬ 
ory as is necessary in DOS. OS/2 
runs only on personal computers 
built with the Intel 80286, 80386, 
and 80486 processors. AIX PS/2 re¬ 
quires an 80386 or 80486 processor. 

Both OS/2 and AIX PS/2 can run 
multiple programs concurrently, 
without their applications using any 
elaborate programming to share sys¬ 
tem resources. OS/2 programs also 
can contain multiple tasks that 
allow a single application program 
to do several things concurrently. 

Like DOS, OS/2 was designed to be 
used by a single person on a single 
personal computer; therefore, OS/2 
does not contain any data security 
or performance monitoring code. Be¬ 
cause multiple programs can be ac¬ 
tive concurrently, data integrity 
functions are required. OS/2 does 
ensure that data files are used by 
only one program at a time. As dis¬ 
cussed later, AIX PS/2 is a multi¬ 
user system and has much greater 
built-in security. 

OS/2, like DOS, is designed to be 
run only on IBM personal comput¬ 
ers or other compatible systems. 

AIX PS/2 only runs on the PS/2. 
There are AIX versions for the 
RISC System/6000, RT®, and Sys¬ 
tem/370™ that allow an AIX PS/2 
application to be moved easily to 
any of these other systems. 

OS/2 comes in two versions: Stan¬ 
dard Edition and Extended Edition. 
Standard Edition is a direct replace¬ 
ment for stand-alone DOS systems, 
while Extended Edition adds a com¬ 
munications manager and database 
manager package to the base stan¬ 
dard edition system. With these 
functions integrated into the system, 
it is easier to develop integrated ap¬ 


plications for OS/2 than it is for 
DOS. 

Because OS/2 operates similarly to 
DOS, little training is needed for 
users migrating from DOS. 

Portable Systems 

The IBM AIX System is a deriva¬ 
tive of the UNIX system originally 
developed by Bell Labs in the late 
1960s and early 1970s. From the be¬ 
ginning, UNIX was designed to be 
a multiuser, multitasking system. 
UNIX is organized similarly to 
DOS and OS/2. However, because 
it is a multiuser and multitasking 
system, it provides security as an in¬ 
herent system function. 

UNIX became popular in part be¬ 
cause it was so easy to modify. 
AT&T® distributed the UNIX 
source code, allowing users to tailor 
the system to suit their needs. 

Because UNIX was very easy to 
modify, at least 13 different semi¬ 
compatible derivative systems ap¬ 
peared on the market, leading to 
confusion and incompatibilities. In 
1988, the Open Software Founda¬ 
tion (OSF™) was formed to solve 
this problem. OSF uses a significant 
portion of AIX Version 3 as the 
basis for a compatible version of 
UNIX. 

AIX maintains the design it inher¬ 
ited from the UNIX system. Its pro¬ 
grams are portable across a wide 
range of IBM systems, including 
the PS/2, RT, RISC System/6000, 
and System/370™. 

While DOS is used more than any 
other operating system, UNIX and 
its derivative systems run on a 
greater variety of computers than 
other operating systems. 





Applications Layer 

User Shell Layer 

Kernel Layer 

Hardware Layer 




Figure 1. DOS Layer Structure 


Because of limited function of 
DOS, it is relatively easy to learn. 
While AIX PS/2, like the other 
UNIX derivative systems, is much 
more powerful than DOS, it is also 
probably the most difficult operat¬ 
ing system for microcomputer users 
to learn. This is due to its large num¬ 
ber of system commands. OS/2 falls 
somewhere in between. 

Architecture 

DOS Architecture: DOS can be 
thought of as having several layers 
(Figure 1). The first, or lowest 
layer, is the physical hardware it¬ 
self. Built on, and maybe in, the 
hardware is the BIOS, which is a 
Read-Only Memory (ROM)-based 
group of software routines used to 
control the hardware. When a PC is 
considered IBM-compatible, that 
PC has a similar BIOS interface. 

The BIOS contains low-level con¬ 
trol functions, rudimentary device 
drivers, and other code required to 
initialize (boot) the system. 

The next higher layer is the DOS 
kernel, which is the heart of the sys¬ 
tem. This portion provides the com¬ 
munication between application 
programs and the BlOS/hardware 
layers. The DOS kernel has the ap¬ 
plication program interfaces (APIs) 
that provide hardware independence 
to the application programs. The ker¬ 
nel is loaded when the system is 


Personal Systems/Issue 2, 1991 










32 


1 MB 
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Display Buffers 


COMMAND.COM - Transient Portion 



User Program Area 
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Buffers, Control Areas, Loadable Device Drivers 



IBMDOS.COM - Interrupt Handlers for 1NT 21 Functions 



IBMBIO.COM - DOS to ROM Interface Routines 



DOS Communications Area 



ROM Communications Area 


OKB 

Interrupt Vector Table 




Figure 2. Map of DOS RAM 

started and always remains in 
memory. 

The highest layer is the command 
processor or shell that contains the 
COMMAND.COM program. This 
program gives users the familiar C> 
prompt. 

Many system commands are exe¬ 
cuted from within 

COMMAND.COM; however, some 
commands, known as external com¬ 
mands, are really separate pro¬ 
grams. COMMAND.COM loads 
and executes these programs as 
needed. All application programs 
can be thought of as external com¬ 
mands because, like external com¬ 
mands, they are loaded and 
executed by COMMAND.COM. 

COMMAND.COM has two sec¬ 
tions: the resident portion, which 
loads next to the kernel; and the 
transient portion, which is located at 


the top of the available system mem¬ 
ory (but still below the 640 KB 
line). The transient portion is re¬ 
loaded as needed after an applica¬ 
tion program or external command 
ends. This makes the maximum 
amount of memory available for ap¬ 
plication programs. 

The application programs are the 
highest layer in the system. These 
programs actually “do the work” for 
the system’s user. 

System memory organization, 
which is shown in Figure 2, is ex¬ 
plained in IBM Disk Operating Sys¬ 
tem Version 4.00 Technical 
Reference (15F1420) pages 6-2 
and 6-3. 

OS/2 Architecture: The OS/2 sys¬ 
tem looks very much like DOS. 

This is because it has the same 
basic layers. 


In the memory map shown in Fig¬ 
ure 3, the systems are again very 
similar. The main difference is the 
use of the memory beyond the 1 
MB limit of DOS. 

The user interface looked the same 
in the first release of OS/2. The 
command structure is the same; the 
main difference is the name of the 
programs. For example, the shell 
program is called 
COMMAND.COM in both DOS 
and the DOS compatibility box of 
OS/2. The shell is named 
CMD.EXE in OS/2 protected-mode 
sessions. 

Beginning with version 1.1, OS/2 
added a Graphical User Interface 
(GUI) referred to as Presentation 
Manager. This presents a more 
“user friendly” interface, because it 
is mouse-driven and provides helps 
to users when needed. 

Another significant way that OS/2 
differs from DOS is that it’s a vir¬ 
tual storage system. With OS/2, one 
can start more programs than will 
physically fit into system memory. 
When this happens, OS/2 memory 
is considered to be overcommitted. 
Programs are swapped out of mem¬ 
ory until sufficient memory has 
been freed to accommodate the re¬ 
quest that started the swapping 
process. 

Beginning with OS/2 Version 2, de¬ 
mand paging handles memory over¬ 
commitment. This requires the 
support of the Intel 80386 micropro¬ 
cessor; therefore, this system release 
cannot run on an IBM AT or Intel 
80286-based PS/2 systems. 

Another characteristic that makes 
OS/2 unique among these systems 
is that it’s a preemptive, time-criti¬ 
cal, multitasking system. 
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Real Mode Program Area * 
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Dual Mode Device Drivers 
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Figure 3. OS/2 Memory Map 


AIX Architecture: UNIX was de¬ 
signed to be used on various types 
of computers. While UNIX contains 
some Assembler routines, it is pri¬ 
marily written in a high-level lan¬ 
guage known as C with just a small 
amount of Assembler code. There¬ 
fore, UNIX can be run on any sys¬ 
tem that has a C compiler. AIX is 
the version designed to run on IBM 
systems. 

AT&T gave universities the right to 
use the UNIX system, which fos¬ 
tered many enhancements to the 
basic system. The most common 
versions of the system available 
today are UNIX System V, released 
by Bell Labs in 1983, and the BSD 
4.2 or 4.3 systems that were devel¬ 


oped at the University of California 
at Berkeley. 

The user interface is similar to 
DOS, except it has a $ as the 
prompt. AlXwindows, a new graphi¬ 
cal interface based on the MIT 
X Window System™, is now avail¬ 
able. AlXwindows is similar in con¬ 
cept and appearance to OS/2 
Presentation Manager. 

AIX has the same basic layered 
structure as DOS and OS/2. Like 
OS/2 Version 2, AIX is a virtual 
storage system. AIX can swap com¬ 
plete processes out of memory and 
simultaneously do demand paging. 


Unlike DOS and OS/2, AIX is de¬ 
signed to run on many different 
types of computers. The kernel 
layer in Figure 4 is tailored by IBM 
for a specific system processor, 
such as the PS/2, RT, RISC Sys¬ 
tem/6000, or System/370. AIX cre¬ 
ates the required 

device-independent appearance for 
the higher level user shell and appli¬ 
cation layers. 

AIX PS/2 offers two different user 
shells, the Bourne shell and the C 
shell. The Bourne shell, which is 
the default, was developed by 
AT&T. The C shell, with syntax 
closely matching the C language, 
was developed later. (AIX PS/2 
does not include the other widely- 
used UNIX shell, the Korn shell, 
which is the default on RISC Sys¬ 
tem/6000 systems.) AIX PS/2 is a 
merger between version 2 of the 
AT&T system and the BSD 4.3 
function, all in a unique UNIX 
system. 

DOS Merge 

Another interesting alternate shell 
for DOS users is called DOS 
Merge. This shell actually copies 
the files from the DOS 3.30 distribu¬ 
tion disk into the AIX PS/2 file sys¬ 
tem, making most DOS commands 
available. After AIX users enter the 
command, “DOS”, they can execute 
familiar DOS commands like DIR 
or use their familiar text editing pro¬ 
gram. They can also run other stan- 


Figure 4. AIX Layer Structure 





Applications Layer 

User Shell Layer 

Kernel Layer 

Hardware Layer 




Personal Systems/Issue 2, 1991 































34 



dard DOS applications from the 
command line, just as they would in 
a DOS system. 

Because AIX PS/2 filenames can be 
longer than those allowed by DOS, 
the AIX PS/2 system maps the 
longer AIX filenames to meet DOS 
requirements, allowing DOS pro¬ 
grams to access these files. 

Another way to use DOS Merge is 
to enter DOS command names on 
the AIX command line. This way, 
DOS and AIX commands can be 
intermixed without actually getting 
into the DOS environment. This 
technique could be used to start a fa¬ 
miliar DOS shell program while run¬ 
ning AIX programs. 

File Systems 

Directory Structure: Externally, 
the DOS and OS/2 file systems look 
similar to AIX. This is because 
DOS and OS/2 designs were concep¬ 
tually based on the UNIX system, 
as was AIX. In all of these systems, 
the file structure (Figure 5) looks 
similar to an upside-down tree, with 
a single directory called the root di¬ 
rectory and multiple levels of sub¬ 
directories branching out below the 
root. 


When listing files in a directory, 
two interesting entries will be en¬ 
countered. They are the dot (.) and 
dot-dot (..) entries. One common 
feature of these systems is using dot 
(.) and dot-dot (..) directory names. 
The dot (.) directory is the current 
one, and the dot-dot (..) directory is 
the parent directory. Therefore, to 
move up one level in the directory 
structure, enter cd .. on the com¬ 
mand line. The only time this is not 
true is when the root directory is the 
current one and there is no higher 
directory level. 

File Naming Conventions: In 

DOS and OS/2, except for files on 
High Performance File System 
(HPFS) devices, filenames are lim¬ 
ited to 11 characters, which is an 
eight-character name followed by a 
(period), followed by a three- 
character extension. This was done 
in the original release of DOS for 
compatibility with the CP/M system. 

In the AIX PS/2 and OS/2 HPFS 
file systems, filenames can be up to 
255 characters and may or may not 
contain one or more periods. 

In DOS and OS/2, the system deter¬ 
mines the use of a file by its file ex¬ 
tension. Executable programs have 
a file extension of either .COM or 
.EXE. Files with an extension of 


.BAT in DOS and in the DOS com¬ 
patibility sessions of OS/2, and 
.CMD in OS/2 protected-mode ses¬ 
sions, are text files containing 
scripts of commands executed by 
the command processor. 

AIX does not use a filename to de¬ 
termine its function. Instead, the 
file’s attribute flags in the directory 
contain this file information. If a 
file can be executed either as a pro¬ 
gram or as a shell script, the exe¬ 
cute flag in its directory entry is 
turned on. This gives the user 
greater flexibility in naming files, 
but makes it impossible to deter¬ 
mine a file’s function by its name. 

There is one other interesting quirk 
in the system naming conventions. 

In DOS and OS/2, directory names 
are separated by a back slash, \. In 
AIX, a forward slash, / is used in¬ 
stead. While both mean the same 
thing, the / can look strange to expe¬ 
rienced DOS users and vice versa. 

Wildcards: The AIX system has 
far greater flexibility when using 
wildcards in commands with 
filenames. In both DOS and OS/2, 
the use of wildcards is limited to 
the * and ? character to represent 
any character or characters. 

In AIX, patterns and ranges of val¬ 
ues also can be used. The * and ? 
are used as in the DOS and OS/2 
systems, but AIX introduces the 
[ ] and [ - ] which are inclusive list 
operators. 

The character in a filename must 
match the characters in the [ ] ex¬ 
actly or be in the range indicated by 
the [ - ] symbols. For example, 
ab[cde]* would include all files be¬ 
ginning with the letters ab and fol¬ 
lowed by either c, d, or e. This also 
could be written ab[c-e]*. 
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DOS 

OS/2 

AIX 

Description 

APPEND 

DPATH 


Set search path to be used by the system for program data if the data file is not 
found in the current directory 

CHDIR 

CH 

CHDIR 

CH 


Change the current directory, or display current directory if no parameters are added 
(abbreviated CD) 

cd 

pwd 

Change current directory 

Display present working directory 

CHKDSK 

CHKDSK 

fsck 

Check structure of disk or file system 

CLS 

CLS 

clear 

Clear screen 

COMP 

COMP 

cmp 

Compare two files 

comm 

Compares files, line by line 

COPY 

COPY 

cp 

Copy files 

DATE 

DATE 

date 

Set system date 

DIR 

DIR 

Is -s 

List the files in a directory 

li 

List the files in a directory 

ERASE 

DEL 

ERASE 

DEL 

rm 

Erase (remove) a file 

del 

Delete a file with confirmation 

FIND 

FIND 

find 

grep 

Find text in a file 

FORMAT 

FORMAT 


Format a new diskette 

mkfs 

Make file system, including superblock, inodes, and datablocks 

MKDIR 

MD 

MKDIR 

MD 

mkdir 

Make a new subdirectory 

PATH 

PATH 

PATH 

Set search path used by system to locate commands 

PRINT 

PRINT 

print 

Print a file or get status about print job 

PROMPT 

PROMPT 


Change the command prompt 

RENAME 

RENAME 

mv 

Rename (move) a file. (May be abbreviated REN in DOS and OS/2) 

REPLACE 

REPLACE 


Copy files only if an existing file already exists on target device 

RD 

RD 

rd 

Remove a directory from a disk. In AIX. rm -r will erase all files in the directory 
and its subdirectories, then will remove the directories. 

SET 

SET 

set 

Display an environment parameter 

SET 

SET 

env 

Set an environment parameter for execution of one command 

SET 

SET 

set 

Clear an environment variable 

SORT 

SORT 

sort 

Sort a file 

TIME 

TIME 

date 

Set system time 

TYPE 

TYPE 

cat 

Display a file on the screen 

bfs 

Display a file on the screen 

Pg 

Display a file, one page at a time 

XCOPY 

XCOPY 


Copy files into respective subdirectories on target disk 


Figure 6. Common DOS, OS/2, and AIX PS/2 Commands 
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OS/2 

AIX 

Description 

DETACH 

& 

Run a process in the background. (In AIX, the is ap¬ 

pended to the end of the regular command.) 

HELP 

man 

Display the online manual 

MOVE 

mv 

Move a file to a different subdirectory 

PSTAT 

ps 

Display process status 

START 

open sh 

Start a program as a separate process 


Figure 7. OS/2 Commands 


The ! is used to indicate not, so 
[!a]* would indicate all files that do 
not start with the letter a. This gives 
the AIX system very powerful file 
manipulation capability. 

System Commands 

According to the IBM command ref¬ 
erence manuals, DOS Version 4.00 
has 66 commands, OS/2 Standard 
Edition Version 1.2 has 93, OS/2 
Extended Edition has 137, and AIX 
PS/2 Version 2.0 has approximately 
300 commands. 

Figure 6 compares commonly used 
DOS, OS/2, and AIX commands. 
The table starts with the DOS com¬ 
mand, followed by the equivalent 
OS/2 command (because it is a logi¬ 
cal extension of DOS), and ends 
with the equivalent AIX command. 
Following this is a brief description 
of each command’s function. 

OS/2 has more commands than 
DOS. New OS/2 commands and 
their AIX equivalents are shown in 
Figure 7. Figure 8 lists commands 
unique to AIX (and UNIX). 

With DOS, only one command may 
be entered at a time, whereas with 
OS/2 and AIX PS/2, multiple com¬ 
mands may be entered. Both OS/2 
and AIX PS/2 provide for the condi¬ 
tional execution of a command 
based on the results of the com¬ 
mand preceding it. For example, the 


link command runs only if the com¬ 
pile was successful. 

OS/2 and AIX PS/2 also provide a 
way to do the opposite and only run 
a command if the preceding com¬ 
mand fails; for example, starting an 
editor to look at error messages that 
have been logged if a compile fails. 

AIX PS/2 has command substitu¬ 
tion, which is a unique capability 
not found in DOS or OS/2. If a com¬ 
mand is enclosed in back quotes, 
for example ‘date 4 , the output of 
that command is substituted in place 
of the ‘date 4 string in the command. 
This allows variable data to be used 
in a system command. 

Note: AIX commands are case-sensi¬ 
tive; DOS and OS/2 commands are 
not. 

The commands shown in Figure 8 
are unique to AIX. While this list is 
far from complete, they are exam¬ 
ples of the types of commands 
found in AIX. In some cases, sim¬ 
ilar commands are available for 
DOS and OS/2 as separate utility ap¬ 
plication packages. Each AIX shell 
also has its own set of commands, 
which are listed with the shell de¬ 
scriptions in the AIX PS/2 com¬ 
mand reference manual. 


Environment Variables 

The environment is an area in mem¬ 
ory that contains strings of text asso¬ 
ciated with a text identifier. For 
example, if the command SET 
NAME=SYSTEM1 is entered at the 
command prompt, the string 
NAME=SYSTEM1 would be cop¬ 
ied into the environment area. A 
program could later read this string, 
and some action could be taken 
based on the value associated with 
the variable NAME. For example, 
the program could use the name 
SYSTEM 1 in a report heading. This 
value could be used to change the 
execution flow of a shell script or 
batch file. 

All of these systems use environ¬ 
ment variables. In DOS, the only 
variable established automatically 
when the system starts is 
COMSPEC. This variable tells the 
system where COMMAND.COM is 
located if it needs to be reloaded 
after a program has overlaid the 
transient portion in memory. 

OS/2 sets different variables that are 
dependent on the system version 
and the options selected at installa¬ 
tion time. Typical variables are 
PATH and DPATH, which tell the 
system where to look for program 
and data files. The PROMPT envi¬ 
ronment variable is used to make it 
easier to differentiate the protected- 
mode sessions from the DOS ses¬ 
sions. Other variables are HELP, 
BOOKSHELF, and KEYS, all of 
which tell the system that certain 
functions are needed or where help 
files are located. 

DOS and OS/2 users are just begin¬ 
ning to take advantage of the envi¬ 
ronment. For example, most 
compilers now use the environment 
to locate needed libraries, temporary 
files, and so forth. 
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AIX systems make greater use of 
the environment to control the flow 
of execution in shell scripts, protect 
data, and so forth. 

Several variables are used with the 
Bourne shell. HOME defines the 
user’s home directory. This is the 
current directory when the user logs 
on to AIX PS/2. PATH is the same 
as for DOS and OS/2. PS1 is the 
prompt string displayed on the com¬ 
mand line. If a command continues 
beyond one line, PS2 is the prompt 
string displayed on the second and 
succeeding command lines. 

The AIX PS/2 system is a multiuser 
system, which means that both the 
system and programs must identify 


the user and the terminal type being 
used. The following variables are 
used for this purpose: LOGNAME, 
LOGTTY, USER, and TERM. 

The LIBPATH, MAIL, 
MAILCHECK, SHELL, and TZ 
(TIMEZONE) variables are also set 
at logon time. Other variables may 
be defined at logon time if they are 
set up in the user’s profile by the 
system administrator. 

The other shells each have their 
own set of standard variables. For 
example, one interesting variable in¬ 
cluded in the C shell is noclobber. 

If this variable is set, files will not 
be written over, or clobbered, by 


other files because of redirected 
output. 

There is another significant differ¬ 
ence in the way the environment is 
handled between AIX PS/2 and the 
other systems. In both DOS and 
OS/2, all set environment variables 
are passed to child processes or pro¬ 
grams when they are started. How¬ 
ever, this is not true in AIX. AIX 
does not pass all variables to a child 
process. If a child process needs an¬ 
other variable, a specific export 
command must be issued for that 
variable. Only those variables estab¬ 
lished at logon time are passed. 


COMMAND 

Description 

alias 

Allows user to rename commands - C shell only 

ar 

Archive utility (similar to DOS ARC or LOADRAM) 

at 

Run a command once at a specified time 

awk 

Almost a complete database package, “awk” searches files and formats output; “awk” stands for the last 
names of its authors: Aho, Weinberger, and Kemighan. See the reading list for more information. 

cron 

Execute a command at scheduled intervals 

df 

Displays free space on a disk 

dircmp 

Compare two directories and the contents of all files found in both directories 

find 

Locate files in the file system 

kill 

End active processes 

In 

Create file links (aliases) 

mount 

Connect physical disk drive to logical file system 

mvdir 

Rename (move) a directory 

nroff/troff 

Text formatting commands that include justification, hyphenation, page numbering, font selection, and so forth 

P F 

Paginate file before printing with “lp” command 

shutdown 

This command must be used to stop the system before it is powered off. This ensures that all control informa¬ 
tion for the file system kept in memory is saved on the disk drives. 

spell 

Check spelling 

tail 

Display last lines of a file 

touch 

Set date and time of a file 

tr 

Translate characters in a file 

wc 

Count lines, words, and characters in a file 


Figure 8. Commands Unique to AIX 
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Shell Programs, Batch Files, 
REXX 

To compile a program, it is often 
necessary to execute and re-execute 
the same command or group of com¬ 
mands. Sometimes it is also neces¬ 
sary to execute a long sequence of 
commands in a specific order. The 
purpose of batch files, or shell 
scripts as they are called in AIX 
PS/2, is to simplify these tasks. 

A batch file is a text file that con¬ 
tains a sequence of commands. 

When the batch filename is entered 
as a command, the system reads the 
file and executes the commands 
sequentially. 

In both DOS and the DOS compati¬ 
bility session of OS/2, a batch file is 
a text file with a .BAT extension. In 
an OS/2 protected-mode session, the 
batch file has an extension of 
.CMD. (“.CMD” stands for “com¬ 
mand,” which is another name for 
this type of file.) The names differ 
to help users distinguish batch files 
with DOS commands from com¬ 
mand files containing OS/2 pro¬ 
tected-mode commands. 

The most commonly executed batch 
files are probably the 
AUTOEXEC.BAT and 
STARTUP.CMD files that are exe¬ 
cuted each time DOS and OS/2, re¬ 
spectively, are booted. The .profile 
shell script is executed when users 
log on to AIX. 

Frequently, it is not sufficient to 
simply execute a predefined se¬ 
quence of commands. It is often nec¬ 
essary to take different actions 
depending on the results of one of 
the commands. For example, if the 
command sequence compiles a file, 
adds it to a library, and then links 
the program with other library mem¬ 
bers, the library and link steps 


should be skipped if the program 
had compilation errors. 

To do this, program return codes 
must be tested and branches made 
in the batch file depending on the 
test results. 

Batch files are commonly used to in¬ 
stall programs. This process re¬ 
quires the ability to determine if 
specific files already exist on the tar¬ 
get disk. 

The batch file capability that comes 
with DOS and OS/2 contains these 
fundamental capabilities. Batch files 
can also test and set environment 
variables, test command parameters 
against text strings, and perform 
simple looping. 

OS/2 Extended Edition Version 1.2 
and both Standard and Extended 
Editions of Version 1.3 include 
REXX, an enhanced command lan¬ 
guage. Because REXX is designed 
to be used by end users, its proce¬ 
dures can be clearly structured and 
easy to understand. 

REXX procedures are often more 
complex than simple .BAT or 
.CMD procedures even though they 
have a .CMD file type. REXX pro¬ 
cedures cannot be executed in the 
DOS compatibility session. 

One important capability of REXX 
is its ability to receive input interac¬ 
tively from the user. For example, 
to insert a user’s name in the com¬ 
mand prompt, the PULL command 
will accept the text string from the 
user. This is not possible under 
DOS or in regular OS/2 command 
procedures. 

The AIX PS/2 system has similar 
power. Like REXX, AIX shell 
scripts can accept user input, which 


can then be used to control the 
script’s execution path. 

Graphical User Interfaces 

Graphical user interfaces, or GUIs, 
may affect your choice of system. 
The concept of a graphical user in¬ 
terface was originally developed at 
the Xerox® Corporation in the 
1970s. It was here that the ideas for 
icons, mouse, and graphical control 
of computer systems were first 
developed. 

Why Use a GUI? It has been 
shown that graphical interfaces 
make new applications easier to 
learn. With the GUI, all applications 
look similar. But for those applica¬ 
tion software users who have consid¬ 
erable experience, the GUI may be 
more of a hindrance than a help. 
Competent users will often have de¬ 
veloped keyboard macros or other 
shortcuts for their main applications 
that do not translate to the GUI 
interface. 

The real advantage of the GUI may 
not be the graphical interface, but 
its ability to share data between pro¬ 
grams. GUI’s cut-and-paste capabil¬ 
ity enables data to be shared among 
multiple applications. 

For example, when running 
Microsoft’s Excel and Word™ under 
Windows or Presentation Manager, 
spreadsheet charts and tables from 
Excel can automatically be included 
in a text document written with 
Word. This way, a significant 
amount of repetitive typing could be 
automated. But a GUI would stream¬ 
line this process. 

One major advantage of installing 
OS/2 Version 2 or Windows Ver¬ 
sion 3 is their ability to run multiple 
DOS applications simultaneously in 
windows with cut-and-paste 
capability. 
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In effect, with OS/2 Version 2 and 
Windows Version 3, users can run 
their existing DOS programs while 
taking advantage of the advanced 
cut-and-paste capabilities of the 
graphical window environment. 

This is accomplished without addi¬ 
tional cost and with little effort, 
which could be a significant produc¬ 
tivity gain. OS/2 Versions 1.2 and 
1.3 can also do this between text- 
based, protected-mode programs if 
they are run in a Presentation Man¬ 
ger text window. 

The basic difference between the 
Windows 3 and OS/2 Presentation 
Manager is the smoothness of the 
user interface. The Windows pro¬ 
gram runs on DOS, which does not 
have the functional capabilities 
found in OS/2. This gives the OS/2 
implementation of similar function 
a smoother, more responsive feel. 

DOS: In 1984, Microsoft released 
the first version of its Windows pro¬ 
gram for the DOS operating system. 
The 8088, with its low system per¬ 
formance, was not fast enough to 
support the overhead required of the 
graphical interface, and the 640 KB 
memory limit did not leave enough 
room for significant application pro¬ 
grams after Windows was loaded. 

The 80386 is the first Intel micro¬ 
processor in the 808X family that 
was designed after the PC became 
available. One of its features was a 
new mode of operation, called Vir¬ 
tual 8086 or Virtual Machine mode. 
This mode, which is available on 
both the 80386 and 80486 micropro¬ 
cessors, allows the system to emu¬ 
late, in hardware, multiple complete 
8086 systems. This is the most com¬ 
mon form of DOS-compatible multi¬ 
tasking available now. 

Each application sees its own 8086 
machine and is not aware that other 


programs are actually running in the 
same system. The multitasking pro¬ 
gram uses the hardware features to 
trap accesses to shared memory or 
devices and allocates or schedules 
them so programs function without 
interference. 

As systems became more powerful, 
Windows was upgraded, until 1990, 
when Version 3 was released. Win¬ 
dows Version 3 supports the virtual 
machine or virtual 8086 capability 
of the 80386 and 80486 micropro¬ 
cessors as well as supporting pro¬ 
tected-mode operation with the 
80286, 80386, and 80486 micropro¬ 
cessors. On these systems, perfor¬ 
mance is acceptable - even with the 
windowing overhead in the system. 



Unlike Windows and 
Presentation Manager, 
the X Window System is 
client/server based. 


Between 1985 and 1990, Microsoft 
also refined the appearance and 
function of the Windows program. 
When version 3 was released, it op¬ 
erated smoothly and was enhanced 
by the availability of numerous 
third-party programs. 

OS/2: OS/2 was jointly developed 
by Microsoft and IBM, and was an¬ 
nounced in 1987. At that time, Pre¬ 
sentation Manager was announced 
as part of OS/2 Version 1.1, which 
became available in 1989. 

Microsoft gained considerable expe¬ 
rience with its Windows program, 
and IBM had graphics experience 
with GDDM in the mainframe envi¬ 


ronment. OS/2 Presentation Man¬ 
ager now presented a powerful inter¬ 
face with capabilities beyond those 
in Windows. 

Since the release of the Presentation 
Manager in OS/2 Version 1.1, 
Microsoft has redesigned Windows. 
Windows Version 3 looks almost 
identical to the Presentation Man¬ 
ager in OS/2 Version 1.2. 

AIX: There are several graphical in¬ 
terfaces in use in UNIX systems. 

The first GUI for UNIX systems is 
the X Window System, which is a 
network-based graphics windowing 
system that became available in 
1985. X Window is the preferred 
windowing system for UNIX sys¬ 
tems and is used by many large cor¬ 
porations, including IBM. 

Unlike Windows and Presentation 
Manager, the X Window System is 
client/server-based. This means that 
applications, or portions thereof, 
can be run on different machines 
across a network, not just on the 
user’s local computer. In effect, a 
person with a network-connected 
system could run a remote UNIX 
database program in a window even 
though the local computer is run¬ 
ning DOS. 

The OSF developed a standard 
GUI, called Motif™, that is based on 
X Windows. It is the most promis¬ 
ing UNIX GUI, although it does not 
have all the functions that should be 
a part of a GUI. For example, it has 
no file manager or graphics func¬ 
tions. However, IBM’s DESKTOP, 
which is based on Motif, can be 
used to provide the file manager 
functions. Graphics programs can 
be written using the lower-level X 
Windows calls from the Motif appli¬ 
cation. AlXwindows also includes 
all of these features. 
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Functional Comparison 


DOS 

OS/2 

AIX PS/2 

Open System 

No 

No 

Yes 

Portable to OEM 

No 

No 

No 

Portable Applications 

Yes 

Yes 

Yes 

Multiuser 

No 

No 

Yes 

Multitasking 

No 

Yes 

Yes 

Architecture 

16 bit 

16 bit (1) 

32 bit 

SAA Compatible 

No 

Yes 

No (2) 

File System 

Yes (3) 

Yes 

Yes (4) 

Minimum CPU Required 

8088 

80286 (5) 

80386SX 

RAM Required 

256 K 

2 MB 

6 MB 

Case-Sensitive Commands 

No 

No 

Yes 

1 - OS/2 Version 2.0 is 32-bit 

2 - AIX PS/2 will be SAA-compatible when POSIX standards will not be violated 

3 - DOS 4.00 only 

4 - When running DESKTOP 

5 - OS/2 Version 2.0 requires 80386SX 


Figure 9. Functional Comparison of DOS, OS/2, and AIX PS/2 


An interesting alternative is the 
NextStep™ environment, which IBM 
offers on AIX. NextStep, which is 
not a network-based system, has 
powerful object-oriented tools, 
much like those found in the OS/2 
Presentation Manager. 

Summary 

This article has presented the capa¬ 
bilities, similarities, differences, and 
limitations of the DOS, OS/2, and 
AIX PS/2 operating systems to help 
you determine which system is ap¬ 
propriate for your requirements. 
These are summarized in Figure 9. 

In summary, DOS is the operating 
system of choice for users with 
small systems, or for users who 
want the easiest system to learn. It 
has few commands, which are not 
case-sensitive and generally are sim¬ 


ple words. There is a large variety 
of relatively inexpensive software 
available for DOS. 

OS/2 is an extension of DOS. It re¬ 
quires a more powerful system, but 
uses many of the same commands 
and has the same disk structure, 
making for a relatively easy migra¬ 
tion from DOS. It is the logical sys¬ 
tem for DOS users whose needs 
have grown more complex. 

AIX PS/2 is the most powerful and 
complex of the three systems. It is 
designed for multiple users who 
share the same computer or who 
need compatibility or connectivity 
with UNIX systems. AIX PS/2’s 
large number of commands, coupled 
with their case sensitivity and cryp¬ 
tic names, make it more difficult for 
new users than either DOS or OS/2. 


More to Come 

Look for the second part of this arti¬ 
cle in the next issue of IBM Per¬ 
sonal Systems Technical Solutions. 

It will contain a more detailed tech¬ 
nical explanation of how these sys¬ 
tems operate. 

Editor s note: In 1989, IBM and 
Microsoft announced their intention 
to deliver a 32-hit version of OS/2. 
That version is referred in this arti¬ 
cle as OS/2 Version 2.0. No formal 
announcement (official product 
name, content, availability, and so 
on) has been made by the m >o com¬ 
panies. Reference to OS/2 Version 
2.0 does not indicate a commitment 
by IBM to introduce a product 
under that name. 
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Programming 
PM Using the 
COBOL/2 
Bindings 

Dave Dill 
IBM Corporation 
Dallas, Texas 

Companies have many options 
when undertaking application de¬ 
velopment for the Presentation 
Manager environment. The use of 
COBOL as the PS/2 development 
language instead of C is one of 
these options. This article points 
out several potential advantages 
to using COBOL and highlights 
the restrictions COBOL imposes. 

Growing support for OS/2 and the 
Presentation Manager (PM) graphi¬ 
cal interface has created a perplex¬ 


ing problem for many companies. 
With thousands of COBOL applica¬ 
tions, millions of lines of COBOL 
source code and legions of COBOL 
programmers, companies are now 
being told that to use OS/2 effec¬ 
tively, they must retrain their pro¬ 
grammers and redesign and rewrite 
their existing applications. 

This understandably creates con¬ 
cern. As they wrestle with limited 
data processing resources, compa¬ 
nies cannot always justify rewriting 
stable, well-performing applications 
for the sake of a new interface or a 
new platform. 

The perplexing part of this situation 
is that most people agree that OS/2 
is the best platform for future 
growth and many indicate that OS/2 
will eventually be their personal 
computer operating system of 
choice. The problem is how to get 
from here to there at a reasonable 


cost and within a reasonable time 
period. 

Alternatives to 
Programming in C 

Companies have options when con¬ 
sidering the PM as a potential pro¬ 
gramming environment and they 
should carefully examine each op¬ 
tion. There are alternatives to the ex¬ 
tensive retraining and rewriting 
necessary with a simultaneous con¬ 
version to C language and PM. 

Contrary to popular myth, C is not 
the only language that supports the 
PM environment. COBOL may also 
be used to produce effective PM ap¬ 
plications. While COBOL may not 
be correct for every application and 
designers and programmers may 
still need some C programming ex¬ 
perience, for a vast majority of a 
company’s PC applications, 

COBOL is a real and viable alterna- 
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tive to writing in C. In some cases, 
COBOL can actually increase avail¬ 
able options and reduce conversion 
costs by offering the potential of 
porting existing COBOL applica¬ 
tions to the PC platform. Rework 
would be limited to a new user 
interface. 

The ability to use COBOL as the 
primary programming language 
within the PM environment can 
drastically alter the cost equation 
for an OS/2 - PM conversion. Com¬ 
panies that cannot justify the move 
based upon a simultaneous conver¬ 
sion to C and PM should take an¬ 
other look at the costs and time 
involved with the C language con¬ 
version removed from the equation. 

Here is where savings might be 
realized: 

Reduced Programmer Retraining: 

The requirement to simultaneously 
learn both a new programming lan¬ 
guage and a new programming envi¬ 
ronment can place a heavy burden 
on designers and programmers. 

While retraining is under way, pro¬ 
ductivity falls and delivery dates are 
often extended. The elimination of 
the new language requirement sig¬ 
nificantly reduces retraining time. 

PM education is significantly 
shorter when a COBOL program¬ 
mer is studying COBOL examples 
and writing COBOL sample pro¬ 
grams. The education process is so 
much faster without the parallel C 
language education, that COBOL 
shops intending to convert to C 
should use COBOL for their initial 
PM education. The C language train¬ 
ing can be deferred until the PM ed¬ 
ucation is complete. 

Shorter Development Cycles: 

Staying with the current program¬ 
ming language could mean staying 


within the existing development sys¬ 
tem. That means using existing pro¬ 
cedures, methods, coding standards, 
debugging and testing tools. Keep¬ 
ing all of this in place can have a 
big impact on development times 
and product quality. 

Unified Programming Staff: The 

ability to use a common program¬ 
ming staff for program development 
and maintenance across all plat¬ 
forms increases a company’s flexi¬ 
bility. And, it may reduce the size 
of the overall staff. 



There are two distinct 
types of COBOL 
compilers for use with 
PM. 


Program Commonality between 
Platforms: A key justification for 
the C language is its portability 
across all platforms. COBOL, too, 
is portable across platforms. If your 
company is already using COBOL 
for the host platform, using COBOL 
for the PC environment can allow 
implementation of a very flexible 
development environment where 
programs are built using the most 
economical development process 
and run on the most economical 
platform. 

The Different Approaches 
to COBOL Support for PM 

There are two distinct types of 
COBOL compilers for use with PM. 
While each type of compiler pro¬ 
duces approximately the same look 
and feel, they utilize different pro¬ 


gramming approaches and philoso¬ 
phies. To make a proper compari¬ 
son between compilers, it is 
important to understand their differ¬ 
ences and what positive and nega¬ 
tive effects each type might have on 
the development process. 

Extended Compilers: This ap¬ 
proach uses COBOL compilers that 
have been modified and extended to 
accept existing PM calls, support 
the PM Pascal calling structure, and 
produce reentrant PM programs. By 
supporting the existing PM inter¬ 
face, these compilers produce PM 
programs that have no restrictions 
in their support of PM. However, be¬ 
cause these compilers support C ori¬ 
ented PM calls and the Pascal 
calling structure, their coding is 
somewhat more complex than nor¬ 
mal COBOL coding. In that case, 
additional training may be required 
for a programming staff. 

New PM Interface: Rather than 
modifying the compiler to work 
with the existing PM interface, this 
approach changes the PM interface 
to accommodate standard COBOL 
compilers. By supporting COBOL’s 
character-based data values and nor¬ 
mal calling structure, this approach 
produces smoother, more standard¬ 
ized code that is very familiar to 
COBOL programmers. But because 
this approach uses a standard 
COBOL compiler, it produces non¬ 
reentrant programs that have some 
PM support restrictions. In spite of 
the nonreentrant restrictions, how¬ 
ever, this interface supports 94% of 
the 549 common PM programming 
calls, including 100% of the graph¬ 
ics function calls and 99% of the 
window function calls. Twelve new 
PM calls have been added to sup¬ 
port PM requirements that standard 
COBOL compilers cannot process. 
This new character-based PM inter¬ 
face, called the COBOL/2 Bindings, 
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hwndFrame = WinCreateStdWindow (HWND_DESKTOP, WS_VISIBLE, 

fFrameFlags, szMyWindowClass, NULL, 
OL, NULL, ID^RESOURCE, &hwndClient) ; 


Figure 1. The WinCreateStdWindow call using C language 


call 0S2API ’ 


WinCreateStdWindow’ 
using by value HWND-DESKTOP size 4 
by value WS-Style 
by reference FrameFlags 
by reference MyWindowClass 
by value 0 size 4 

by value 0 size 4 

by value 0 size 4 

by value 1 size 2 

by reference hwndClient 
returning hwndFrame. 


Figure 2. The WinCreateStdWindow call using an extended compiler 


call "WICTRS" 


using HWND-DESKTOP, 
WS-Style, 

FrameFlags, 

MyWindowClassSize, 
MyWindowClass, 
NULL, 

NULL, 

NULL, 

NULL, 

ID-RESOURCE, 
hwndClient, 
hwndFrame. 


Figure 3. The WinCreateStdWindow call using the COBOL/2 Bindings 


is part of the IBM OS/2 Program¬ 
ming Tools and Information Kit for 
both versions 1.2 and 1.3. 

To show how these interfaces dif¬ 
fer, Figures 1, 2 and 3 show the PM 
call to create a standard window, 
WinCreateStdWindow. Figure 1 


shows the WinCreateStdWindow 
call written using the C language. 
Figure 2 shows the same call writ¬ 
ten using an extended compiler, and 
Figure 3 shows this call written 
using the IBM COBOL/2 Bindings. 
Each example produces the same 
window. 


The Functions of the 
COBOL/2 Bindings 

There are, for each supported PM 
language, unique requirements that 
are satisfied by language-specific 
PM interface code. This code, 
called the language bindings, is part 
of the OS/2 Programming Tools and 
Information Kit. There are bindings 
for C, Macro Assembler, COBOL 
and FORTRAN. 

The COBOL/2 Bindings include the 
PM character-based interface sup¬ 
porting COBOL’s standard calling 
convention, new COBOL-oriented 
calls to replace the existing C ori¬ 
ented PM calls, predefined COBOL 
structures, constants and messages. 
Specifically, the COBOL/2 Bind¬ 
ings contain: 

• COBOL versions of 527 existing 
PM function calls 

• 12 new COBOL calls 

• 158 PM data structures defined 
in COBOL 

• 1500 OS/2 constants defined in 
COBOL 

• 6700 PM messages and constants 
defined in COBOL, for use in the 
program’s include files 

Software Requirements for 
Using the COBOL/2 
Bindings 

The list of required software for use 
with the COBOL/2 Bindings is 
fairly short. OS/2 Standard or Ex¬ 
tended Edition Release 1.2 or 
higher is required. The COBOL/2 
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These manuals are available only as part of the Programming Tools and Information Kit: 

Programming Guide 

64F0273 

Presentation Manager COBOL/2 Bindings Reference 

64F0280 

Presentation Manager Programming Reference Volume 1 

64F0276 

Presentation Manager Programming Reference Volume 2 

64F0277 

Building Programs 

64F0274 

Control Program Programming Reference 

64F0275 

These manuals can be ordered through an IBM branch office: 


Programming The Presentation Manager Using The COBOL Bindings 

GG22-9463 

Systems Application Architecture Common User Access Advanced Interface Design Guide 

SC26-4582 

Systems Application Architecture Common Programming Interface Dialog Reference 

SC26-4356 

Systems Application Architecture Common Programming Interface Presentation Reference 

SC26-4359 


Figure 4. Documentation for Programming the Presentation Manager Using the COBOL Bindings 


Bindings are not supported by OS/2 
Version 1.0 or 1.1. The COBOL/2 
Bindings from the IBM OS/2 Pro¬ 
gramming Tools and Information 
Kit Version 1.2 or higher must be 
installed and available during the 
compile and link steps. Finally, a 
COBOL compiler capable of pro¬ 
ducing OS/2 protect-mode programs 
must be used. Any compiler speci¬ 
fied software is additional. 

COBOL PM Programming 
Documentation 

A large amount of documentation is 
available for PM programming. 
However, most of it is designed and 
written for C programmers. While 
these books contain good informa¬ 
tion about PM programming, they 
assume that the reader is familiar 
with C, so they present only C or 
Macro Assembler examples. For 
COBOL programmers, these books 
are inadequate. There are, however, 
some books available that can assist 
COBOL programmers when used 
for specific information. Most of 
these books are C oriented, so 


COBOL programmers must be care¬ 
ful using them. 

Figure 4 contains a list of books 
that a COBOL programmer using 
the COBOL/2 Bindings will find 
helpful. These books are in addition 
to the compiler’s documentation 
and should be used as described. 

The Programming Guide is a good 
place to start, especially for 
COBOL programmers new to PM. 
This book gives an overview of the 
PM environment showing the major 
parts of PM and how programs inter¬ 
act with PM. 

Programming the Presentation Man¬ 
ager Using the COBOL Bindings 
shows how to code the basics of a 
PM program when using the 
COBOL/2 Bindings. This book 
shows how PM calls fit together to 
form a standard COBOL PM pro¬ 
gram. All examples are fully ex¬ 
plained, and each chapter contains 
source code for the sample program. 


Presentation Manager COBOL/2 
Bindings Reference shows, parame¬ 
ter by parameter, how to code each 
PM call for a COBOL compiler. 
This is the only COBOL language- 
specific book included with the 
OS/2 Programming Tools and Infor¬ 
mation Kit. 

The two Presentation Manager Pro¬ 
gramming Reference volumes con¬ 
tain the only complete description 
of how each call functions, its asso¬ 
ciated messages and possible return 
codes. These books are written for 
C programmers, so to avoid real 
confusion, read the text and skip the 
call definitions and examples. Use 
the COBOL/2 Bindings book as a 
coding reference. 

PM Functions Not 
Supported by the COBOL/2 
Bindings 

Some PM functions are not avail¬ 
able to nonreentrant COBOL pro¬ 
grams. While the number of 
unsupported functions is small, it is 
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important to understand each of 
these functions and its impact on 
the OS/2 - PM platform to be built. 

Sent messages: Nonreentrant 
COBOL programs may not receive 
synchronously transferred messages 
(referred to as sent messages) from 
PM or other window procedures. 
Even though PM is a message- 
based system, this is not as great a 
restriction as might be assumed. 

First, nonreentrant programs can re¬ 
ceive messages posted directly to 
the message queue. Many PM mes¬ 
sages are posted messages, and non¬ 
reentrant programs can process 
these messages without restrictions. 

Second, PM contains a special Lan¬ 
guage Support Procedure that as¬ 
sists nonreentrant programs in 
receiving and processing sent mes¬ 
sages. Third, while nonreentrant pro¬ 
grams may not receive sent 
messages, they may send these mes¬ 
sages. The ability to send these 
types of messages gives nonreentr¬ 
ant programs the ability to control 
PM windows. 

Specifically, only three PM func¬ 
tions are precluded to nonreentrant 
programs because of the synchro¬ 
nously transferred message restric¬ 
tion. They are: 

• Dynamic Data Exchange - Non¬ 
reentrant programs may not ex¬ 
change data with other PM 
programs via the DDE support 
within PM. 

• Delayed rendering to the clip¬ 
board - Nonreentrant programs 
may cut, copy to, and paste from 
the clipboard, but they may not 
own the clipboard. This pre¬ 
cludes the display of the 
clipboard’s contents and delayed 
rendering of images to the 
clipboard. 


• Owner draw - The ability to add 
graphics to dialogs, their compo¬ 
nents, or menus at the time they 
are displayed is not supported. 
Graphics may be included on dia¬ 
logs at the time they are created. 

Window Subclassing: Because 
nonreentrant programs may not re¬ 
ceive sent messages, they may not 
intercept sent messages destined for 
other window procedures. Window 
subclassing involves intercepting 
these messages and thus is not 
supported. 

Advanced Video Function Calls: 

Commonly called AVIO, this class 
of calls supporting PM text win¬ 
dows is not available to nonreentr¬ 
ant programs. Nonreentrant 
programs do support full-screen 
VIO programs. 

The Heap Manager: This facility 
for managing memory segments and 
memory objects is not available to 
nonreentrant PM programs. 

System Hooks: The ability to set 
hooks within PM and receive early 
notification of events or obtain early 
access to data is not available to 
nonreentrant COBOL PM programs. 

Help Manager: Use of the Infor¬ 
mation Presentation Facility to auto¬ 
matically handle help requests is not 
available to nonreentrant programs. 
The use of the IPF requires the set¬ 
ting of help hooks but the setting of 
system hooks is not supported by 
the COBOL/2 Bindings. All help 
functions within programs using the 
COBOL/2 Bindings must be user- 
written. 


The Language Support 
Procedure for Non reentrant 
Programs 

The inability to receive sent mes¬ 
sages is the most severe restriction 


on nonreentrant COBOL programs. 
The sending and receiving of mes¬ 
sages is the cornerstone of commu¬ 
nications within the PM 
environment. A failure to fully par¬ 
ticipate in this communication pro¬ 
cess would prohibit such a program 
from running within the PM 
environment. 

To assist nonreentrant programs 
with sent messages, PM includes 
special reentrant routines that are au¬ 
tomatically invoked to support all 
windows and dialogs built by a non¬ 
reentrant program. These routines 
are called the Language Support 
Procedure. These procedures inter¬ 
cept messages sent to the nonreentr¬ 
ant program and, based upon the 
importance of the message, either 
posts the message to the program’s 
message queue or processes the mes¬ 
sage on behalf of the program. The 
Language Support Procedure gives 
back to nonreentrant programs the 
ability to receive and process the im¬ 
portant sent messages. 

PM Functions Programmed 
Differently with the 
COBOL/2 Bindings 

Because so much PM function is 
available to a nonreentrant program, 
the real comparison between lan¬ 
guages should be the area of how 
the code must be written - specific¬ 
ally, what must be programmed dif¬ 
ferently when using nonreentrant 
languages. Here are the six major 
parts of a PM program that must be 
coded differently when using the 
COBOL/2 Bindings. 

Window and Dialog Procedures: 

Procedures, as they are defined 
under PM, are not supported by non¬ 
reentrant programs. Nonreentrant 
programs do not have multiple entry 
points, a requirement for PM to au¬ 
tomatically locate and execute dif- 
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ferent procedures for different win¬ 
dows and dialogs. A nonreentrant 
program must receive all messages 
through a common entry point and 
determine which window procedure 
is to receive the message, based 
upon the message handle. Then, it 
performs or branches to the correct 
program routine. There is no limit 
on what these routines can do, only 
that for nonreentrant programs the 
program must determine which rou¬ 
tine gets which message and how 
that routine is to be executed. 

Instance Data: This is data with a 
common definition that varies for 
each procedure. For example, if the 
color of each window were differ¬ 
ent, the color of a window could be¬ 
come instance data, varying by 
window procedure. As instance 
data, PM automatically makes the 
correct color available to each win¬ 
dow procedure through a common 
definition. Nonreentrant programs 
must manage their own save areas 
and determine which data, if any, 
applies to which procedure. 

Notification Messages: These mes¬ 
sages are sent from PM to a proce¬ 
dure to give notification that an 
event has occurred, such as the cre¬ 
ation of a window or a dialog. Noti¬ 
fication messages are sent messages 
and are not available to nonreentr¬ 
ant programs. Nonreentrant pro¬ 
grams can perform all the functions 
usually performed when receiving a 
notification message. These pro¬ 
grams simply branch directly to the 


notification routine after checking 
the PM call’s return code. 

Structures and Constants: Some 
structures and constants cannot be 
declared using standard COBOL 
convention. Special PM calls have 
been added to allow nonreentrant 
COBOL programs to declare and 
work with these structures and 
constants. 

Dynamic Storage Allocation: 

Unlike C programs that can allocate 
and deallocate memory as needed, 
nonreentrant COBOL programs 
must statically declare all PM-re- 
lated save areas, structures, and con¬ 
stants at compile time. 

Special Value of Pointers: Many 
C implementations of PM routines 
make use of known pointer values 
within calculations. Nonreentrant 
PM programs may not access or 
make use of the value of pointers. 

Meeting the Challenge 

Make no mistake about it, the OS/2 - 
PM environment is complex, and to 
achieve all the productivity avail¬ 
able from an OS/2 system, PM ap¬ 
plications should be complex. But 
this complexity should not extend 
the development process itself. Re¬ 
quiring designers and programmers 
to learn a new programming lan¬ 
guage will complicate and lengthen 
the development process. And this 
process is one already under pres¬ 
sure from normal company de¬ 


mands and the introduction of the 
OS/2 PM environment. 

Just as the C language is not the 
only language for every PC applica¬ 
tion, it would be incorrect to claim 
COBOL as the only PM program¬ 
ming language a company will ever 
need. A more realistic scenario is a 
combination of languages, genera¬ 
tors and development tools, each 
able to develop certain types of ap¬ 
plications more efficiently and eco¬ 
nomically. An average OS/2 
programming department might use 
two or three programming lan¬ 
guages, a PM generator and several 
prototyping and debugging tools as 
a normal mix, with selection of the 
exact language or tool based upon 
individual application requirements. 
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Installing and ^ 
Using the DOS 
Database * 
Requester 


Marty Sirkin 
IBM Corporation 
Austin , Texas 



The DOS Database Requester is a 
feature of OS/2 Extended Edition 
1.2 that allows DOS users to ac¬ 
cess databases on OS/2 servers. 
This article contains step-by-step 
instructions to make configuring, 
installing, and building DOS 
Database Requester applications 
a very simple process. 

While the DOS Database Requester 
supports a full subset of SQL state¬ 
ments, it does have some limitations: 

• DOS machines may not be 
database servers - databases must 
reside on OS/2 Extended Edition 
1.2 machines 

• Remote precompiling and bind¬ 
ing is not supported 

— Precompiling and binding 
must be done on an OS/2 EE 
workstation 

— Compiling and linking may be 
done on a DOS machine 

• A few Database Manager™ func¬ 
tions are not supported; see the 
Database Administrator* s Guide 
(S01F-0267) for a list of these 
functions 

The DOS Database Requester uses 
the NETBIOS interface (not APPC 
or SQLLOO) to communicate with 
the OS/2 EE server. This is the 
same protocol that the LAN server 
and LAN requester uses. OS/2 EE 
servers may accept requests from 
both OS/2 EE requesters and DOS 


Database Requesters concurrently, 
provided everything is configured 
properly. 

Installation 

The following steps are necessary to 
install the DOS Database Requester 
on OS/2 EE server workstations and 
on DOS workstations: 

On the OS/2 Extended Edition 1.2 

Server: 

1. Install the workstation as an OS/2 
Extended Edition database server. 

2. Include the DOS Database Re¬ 
quester when asked. 

This should be done on only one 
server workstation, because files are 
copied onto the server’s hard disk 
and later copied onto the DOS 
workstation. 


3. Install NETBIOS support files: 

• NETBDD.SYS 

• ACSNETB.DLL 

by: 

• Changing the flag in the Commu¬ 
nications Manager profile to load 
NETBIOS support and then rein¬ 
stalling, or 

• Copying from another worksta¬ 
tion, or 

• Unpacking them from the installa¬ 
tion diskettes using the UNPACK 
program 

The ACSNETB.DLL file should be 

placed in the \CMLIB\DLL direc¬ 
tory, and the NETBDD.SYS file be¬ 
longs in the \CMLIB directory. 
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To complete the installation, ensure 
that the following statement is on 
one line in the CONFIG.SYS file: 

DEVICE-C:\CMLIB\NETBDD.SYS 
CFG=C:\CMLIB\XXXXXXXX.CFG 

Notes: 

• The statement must follow the 
LANDD.SYS line. 

• XXXXXXXX is the name of the 
configuration file created with 
BCS. If it is not present, add it. 

4. If a 3270 card is installed in the 
server, use the PS/2 reference disk¬ 
ette to ensure the DLC and 3270 
cards have different interrupt levels. 
An interrupt level on 3 is fine for 
the DLC card when both the DLC 
and the 3270 start have an interrupt 
level of 2. 

5. Set the workstation name to a 
unique value, which allows the 
workstation to be located using 
NETBIOS. You may set this name 
when installing the system; it may 
be changed using the System/Recon¬ 
figure Database Manager/Worksta¬ 
tion Name option of Query 
Manager. 

6. Perform a STARTDBM before 
using your server to accept requests 
from DOS workstations. Communi¬ 
cations Manager does not need to 
be started to communicate via 
NETBIOS for the DOS Database 
Requester. 

On the DOS Database Requester: 

The following files can be obtained 
from the DBDRQLIB subdirectory 
of any OS/2 EE 1.2 server after an¬ 
swering “yes” to the question “In¬ 
stall DOS DB Requester?” 

1. Directly under the root directory 
on any drive, create a directory 
called DBDRQLIB. Although the 


DOS Database Requester can run 
from a floppy drive, it’s preferable 
to use a hard drive. 

2. In the new directory, create a file 
called DBDRQLIB.CFG. A tem¬ 
plate of this file is placed on any 
server that includes DOS Database 
Requester. The new file must con¬ 
tain the following three statements: 

SQLNAME = NAME 

NAME is the DOS workstation 
name. This statement is used for 
NETBIOS communications. 

SQLSIZE = BS/WS 

BS is the block size used to trans¬ 
mit data. WS is the work size of 
RAM allocated for the DOS 
Database Requester. These values 
can be adjusted, depending on the 
amount of available RAM, but 4096 
and 16834 are good starting values. 

SQLLIB - DIR 

DIR is a valid path to the rest of the 
DOS Database Requester files. 

There is no restriction against the 
DIR being a path to the 
DBDRQLIB directory itself. This is 
recommended so all DOS Database 
Requester files reside in the same 
directory. 

3. Place the following three mes¬ 
sage files (used internally for DOS 
Database Requester) in the directory 
listed in the DBDRQLIB.CFG file: 

SQLL0G0N.MSG 
SQLZK001.SRC 
SQLZK001.IDX 

4. Place the following two files in a 
directory on the workstation search 
path. Use these files for logging on 
and logging off, giving similar func¬ 
tion to UPM on OS/2. (Note: These 


files may not be needed because 
DOS Database Requester has APIs 
for logging on and logging off.) 

SQLL0G0N.EXE 

SQLL0G0F.EXE 

5. Install PC LAN Support Program 
Version 1.1 (or later) on the DOS 
workstation. This program contains 
device drivers (.SYS files). The 
LAN support program is not part of 
OS/2 EE and may have to be pur¬ 
chased separately (it’s included with 
LAN Server 1.2). Device drivers 
must be listed in the DOS 
workstation’s CONFIG.SYS file. 
Due to dependencies among files, 
they should be listed in the follow¬ 
ing order: 

DXMA0M0D.SYS 

The following arbitrator driver is re¬ 
quired: 

DXMC0M0D.SYS 

Include the following only if token 
ring is used for communications: 

DXME0M0D.SYS 

Include Ethernet® in the following 
if used for communications: (This 
file is available with PC LAN Sup¬ 
port Program Version 1.3 or later.) 

DXMGOMOD.SYS 

Include the following only if PC 
LAN is used for communications: 

DXMT0M0D.SYS 

The following NETBIOS driver is 
required: 

TIMERINT.SYS 

This timer interrupt driver is re¬ 
quired if the machine has BIOS 
dated June 1985 or earlier. It’s not 
required for a PS/2. 
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Stored 

in 

Database 

All steps above this line must be performed on an 
OS/2 workstation connected to the server on which 
the database resides. 


All steps below this line may be performed on 
either an OS/2 or DOS workstation. 



DOS 

Workstation 


Figure 1. How to Build a DOS Database Requester Application 


6. Include cr=y after the NETBIOS 
device driver in the CONFIG.SYS 
file. This forces a hard reset of the 
DLC card when rebooting the 
system. 

Directory 

The DOS Database Requester uses 
a directory to locate databases on re¬ 
mote servers. Databases must be cat¬ 
aloged before they can be accessed 
remotely. The DOS Database Re¬ 
quester includes APIs for cataloging 
and uncataloging databases and also 
for viewing the database directory. 


The database directory for the DOS 
Database Requester is simpler than 
the OS/2 Extended Edition database 
directory structure. All databases 
must be remote, because DOS work¬ 
stations are requesters only. There¬ 
fore, a system database directory 
and volume directory are unneces¬ 
sary. Only the location of the re¬ 
mote database needs to be included 
in the DOS Database Requester 
database directory. Each remote 
database to be accessed is stored as 
an entry in the directory. Each entry 
includes the database name and 
alias, the workstation name of the 


server on which it is located, and 
the adapter (0 or 1) of the DLC 
card. In addition, there are two op¬ 
tional parameters for a comment 
and code page. 

To establish a path from the DOS 
workstation to the database, the 
Database Manager accesses 
NETBIOS and locates the server 
with the given workstation name. 
The server then checks the system 
database directory until it finds the 
proper volume. The volume direc¬ 
tory is checked and locates the cor¬ 
rect directory. 
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Building DOS Database 
Requester Applications 

The DOS Database Requester is a 
powerful tool. This section briefly 
describes the process needed to 
build executable applications for the 
DOS Database Requester. 

Like any application, a source file 
containing SQL statements needs to 
be built. It’s necessary to precomp¬ 
ile and bind the program to the 
database(s) against which it will 
run. Precompilation and binding, 
which must be done on an OS/2 EE 
workstation, is easiest if done on 
the server holding the database. A 
precompile or bind can be done 
from an OS/2 EE Requester work¬ 
station connected to the workstation 
where the database is stored. Pre¬ 
compiling and binding is necessary 
only if the program contains SQL 
statements. 

Once the program is precompiled, 
compilation and linking may be 
done at either the DOS or OS/2 EE 
workstation. Real-mode libraries 
must be used if compilation and 
linking is done on an OS/2 EE work¬ 
station, because OS/2 compilers can 
use protected-mode versions that do 
not work on DOS. After compiling 


and linking is finished, the execut¬ 
able program must be copied back 
to the DOS workstation (Figure 1). 

Solutions to Common 
Problems 

If you encounter a problem during 
this process, verify the following: 

• A STARTDBM has been per¬ 
formed on your server 

• The proper device drivers and 
DLL on the server are installed 
in the correct directories and ref¬ 
erenced in the CONFIG.SYS file 

• Both the requester and server 
NETBIOS names are valid and 
unique on the LAN 

• You have logged onto the DOS 
Database Requester with a valid 
user ID and password 

• All databases to be accessed are 
cataloged correctly 

• After changing the CONFIG.SYS 
and DBDRQLIB.CFG files, you 
have rebooted both the OS/2 
server and DOS Database 
Requester 

If only a small number of DOS 
Database Requester workstations 
can be connected to the database 
server, and the LAN requester or 


LAN server is also running on that 
server, NETBIOS resources must be 
carefully balanced. The default con¬ 
figuration for the LAN requester or 
LAN server in the IBMLAN.INI 
file consumes most of the 
NETBIOS resources. 

Reduce the number of users, names, 
commands, and sessions in the 
IBMLAN.INI file to increase the 
number of allowable DOS Database 
Requester connections. After that, 
be sure to verify that you have not 
made the number of allowable LAN 
requester or LAN server sessions 
less than you require. 
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OS/2 

LAN Server 1.3 
Overview 

Steven French and Roy Feigel 
IBM Corporation 
Austin , Texas 

This article describes OS/2 LAN 
Server 1.3, its purpose, structure, 
and new features. Also described 
are the changes to the DOS LAN 
Requester product shipped with 
it. This new version of IBM’s local 
area network software offers im¬ 
proved performance and usability, 
yet maintains compatibility. 

The OS/2 LAN Server 1.3 was de¬ 
veloped because users wanted in¬ 
creased performance, more features, 
lower memory requirements, and 
better usability in local area net¬ 
work (LAN) software. The server 
software and its corresponding DOS 
and OS/2 requester software, builds 
on the performance improvements 
of the previous version, while main¬ 
taining compatibility with it. 

OS/2 LAN Server 1.3 runs on the 
new OS/2 Extended Edition 1.3. It 
benefits from many of the operating 
system’s improvements to the print 
spooler, loader, and swapper. Other 
changes include improved usability, 
locking, and named-pipe perfor¬ 
mance. The DOS LAN Requester 
has added support for Ethernet net¬ 
work adapters and Microsoft Win¬ 
dows 3.0. 

Some Background 

During the last five years, PC LANs 
have progressed from being an inter¬ 
esting technical curiosity used for 
specialized applications to an inte¬ 
gral part of many businesses. This 
phenomenal growth is expected to 


continue, and with it comes the re¬ 
quirement for faster, easier-to-use 
networks. 

Initially, the PC LAN Program 
(PCLP) allowed small-to-medium- 
size PC networks to share files and 
printers. Its performance constraints 
became apparent; many were be¬ 
cause of limitations of the DOS en¬ 
vironment for which PCLP was 
designed. IBM therefore decided to 
develop with Microsoft an OS/2- 
based server that would deliver bet¬ 
ter performance and be easier to use 
and program than PCLP. The result 
of this unique joint development ef¬ 
fort was OS/2 LAN Server 1.0, and 
in March 1990, OS/2 LAN 
Server 1.2. 

With OS/2 LAN Server 1.2 came 
many new features and a com¬ 
pletely rewritten file server, logon 
server, access control system, and 
DOS LAN Requester. A new com¬ 
mon security system, User Profile 
Management (UPM), that can be 
shared among products, was added. 
Usability was improved. An Appli¬ 
cation Programming Interface (API) 


was published, enabling software de¬ 
velopers to write programs that use 
network features without requiring 
users to remember network com¬ 
mands or menu options. Future ver¬ 
sions of LAN software will use this 
common API, allowing for compati¬ 
bility and interoperability across fu¬ 
ture releases. Many LAN software 
products from other companies sup¬ 
port the same API. 

Customers asked for many changes 
to LAN Server 1.2, including better 
performance. As a result, OS/2 
LAN Server 1.3 was developed to 
meet our customers’ fast-changing 
needs. 

Structure 

As shown in Figure 1, the required 
software running on an OS/2 LAN 
Server machine is divided into sev¬ 
eral parts: 

Network services are constantly run¬ 
ning network applications. 

Network utilities execute for brief 
periods while users execute com- 


What is a Network? 

A network is a collection of resources and the machines that share them, 
and is typically described as having “server” machines and “requester” 
machines. A shared resource can be a group of files and directories, or it 
could be a printer or even a serial device (for example, a modem). The 
processing capacity of a server machine can also be shared by running 
programs submitted from a requester on a server in the server’s mem¬ 
ory. The collection of servers and the resources that they share when 
they are managed as a single unit are referred to by IBM as a “domain.” 

Users do not need to know where a resource is to access it on a properly 
configured domain. Domains also contain collections of user definitions 
and their appropriate access control profiles. Network-connected ma¬ 
chines located within one close geographic area are referred to as a local 
area network, but they may contain more than one domain, and they 
may be connected through bridges. 
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Figure 1. Network Structure 


mands either from network menus 
or from the command line. 

Network API support provides the 
intermediate layer that network ap¬ 
plications and utilities use to access 
network functions. The network 
API layer directly accesses many of 
the network data structures such as 
user and access control information. 

The Redirector acts as an extension 
of the base operating system that re¬ 
routes operating system calls in¬ 
tended for network devices across 
the network. It uses NETBIOS and 
its accompanying lower-level net¬ 
working protocol support. 

Two examples of the interdepend¬ 
ence of the network layers are the 
“AT” command and the “LOGON” 
command. Both descriptions are 
considerably simplified for the pur¬ 
poses of this article. 

The AT Command: The first ex¬ 
ample of cooperation of the layers 
examines the AT command, which 
is used for scheduling a command 
to be run at regular intervals in the 
future. 


When the administrator executes 
this network utility, a data structure 
with the names and times for all reg¬ 
ularly scheduled commands is up¬ 
dated. To verify that the user has 
administrator privilege, the AT com¬ 
mand must call the network API 
(NetUserGetInfo()). The network 
API must then make calls into the 
base operating system to retrieve 
the required information from the 
user accounts list (NET.ACC file). 
Once the command has been sched¬ 
uled, it will be run by a scavenger 
process in the constantly running 
“server” service. The server checks 
when the next AT scheduled com¬ 
mand is to be executed, and when 
the time comes, calls the base oper¬ 
ating system to begin a new com¬ 
mand processor (CMD.EXE) to run 
the scheduled command. 

If the command involves an opera¬ 
tion on a network drive or printer 
(for example, “DIR g:” where g: is 
a network connection to a files re¬ 
source on another server), then the 
redirector will intercept the com¬ 
mand and construct a network com¬ 
mand called a server message block 
(SMB). The SMB is then sent to the 
NETBIOS device driver by the 
redirector. The NETBIOS device 


driver passes the frame to lower- 
level network protocol support (nor¬ 
mally the 802.2 layer), which hands 
it to the network adapter for trans¬ 
mission across the networking ca¬ 
bles to the target server machine. 

Notice how all of the layers cooper¬ 
ated in the execution of a single 
command. 

The Logon Command: Another 
example of the interdependence of 
the layers is the UPM logon option 
from the Desktop Manager menus. 

The logon menu option, and most 
programs selectable from the UPM 
and network menu interfaces, may 
be thought of as network utilities 
just like commands entered from 
the command line. The logon pro¬ 
gram calls the network API layer to 
get the default domain name, then 
calls NetWkstaSetUID2( ) to vali¬ 
date the user ID and password at 
the domain controller. The 
NetWkstaSetUID2() call updates 
data structures in the redirector to 
store the userid and password. 

These may be used later when rees¬ 
tablishing connections to discon¬ 
nected resources and for 
establishing connections to new 
servers. 

The NetWkstaSetUID2() call 
passes to the redirector, which pack¬ 
ages the call and sends it to 
NETBIOS, which sends it to lower- 
level protocol support for transmis¬ 
sion across the network. When the 
call arrives at the domain controller, 
the constantly running logon server 
service (NETLOGON) processes 
the request and passes it back across 
the network to the logon program. 

Network Services 

There are ten network services 
shipped with the LAN Server 1.2 
and 1.3 products (Figure 2.). Be- 
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cause they do not interact with the 
console (keyboard or screen) and 
run until explicitly stopped, they dif¬ 
fer considerably from the network 
utilities. The network services are 
of two types: three requester ser¬ 
vices, which can run on any OS/2 
requester or server machine, and 
seven server services. Programmers 
can easily write custom network ser¬ 
vices of their own by using the 
OS/2 LAN API. 

The largest and most important of 
the services is the server service, 
often called the file server. It is actu¬ 
ally a collection of more than one 
process doing many diverse tasks at 
the same time. Portions of the 
server code are heavily dependent 
on the redirector and network API 
support modules. It uses the most 
memory of all of the network ser¬ 
vices and often requires significant 
tuning for optimal performance. For 
this reason, it was given much atten¬ 
tion during the development of 
OS/2 LAN Server 1.3. Among the 
many changes are its print support, 
memory usage, and improved file 
locking performance. 

With the new spooler contained in 
OS/2 1.3, redirected printing is sig¬ 
nificantly faster and network print¬ 
ing features are easier to operate. 
LAN Server 1.3 can run on ma¬ 
chines with less memory than LAN 
Server 1.2. One of the most signifi¬ 
cant uses of memory in the file 
server is for the allocation of 
“bigbuffs,” which are 64 K buffers 
used for large information transfers 
across the network. These are dy¬ 
namically allocated, and do not per¬ 
manently take up as much memory 
as with previous versions. These 
buffers are useful for servers under 
heavy load servicing large read and 
write requests. Because more mem¬ 
ory is available for LAN Server 1.3, 
a network administrator can change 


Requester Services 

Net popup 

Displays messages on the screen 

Messenger 

Send messages to other users 

Workstation 

General requester support 

Server Services 

Replicator 

Network backup facility 

Server 

Basic file and print serving 

Logon Server (NETLOGON) 

Validates user logons 

PC DOS RIPL 

Support for diskless machines 

Alerter 

Notifies of important network events 

Net Run 

Support for remote program execution 

DLRINST 

Automatic download of DLR to PCLP 


Figure 2. Network Services 


the IBMLAN.INI configuration file 
to allow allocation of more bigbuffs 
on the server. This results in in¬ 
creased performance. 

File locking, one of the most com¬ 
mon network operations, has been 
improved because of changes to 
server lock queueing strategies. 

Some server functions and configu¬ 
ration options have been added. 

More DosDevIoctl calls are sup¬ 
ported across the network and an op¬ 
tion to disable automatic dynamic 
share cleanup has been added. Dy¬ 
namic share cleanup was necessary 
on earlier versions that allowed lim¬ 
ited numbers of network shares to 
be active concurrently. Now, many 
shares can be active at one time, 
and routine cleanup of shares is not 
always necessary. Some administra¬ 
tors prefer dynamic shares be auto¬ 
matically cleaned up when not 
actively in use. Others prefer 
cleanup of dynamic shares by the 
network administrator only. Both op¬ 
tions are now available. 

To speed up many common net¬ 
work operations, such as network 
administration and network logon, it 


was necessary to improve perfor¬ 
mance of some key named-pipe op¬ 
erations. Named pipes are a 
two-way interprocess communica¬ 
tion method used by requesters and 
additional servers for communica¬ 
tion with the logical server and the 
NETLOGON service. Through 
changes to the way named pipes are 
used and to the base operating sys¬ 
tem support for named pipes, simul¬ 
taneous named pipe operations are 
handled better, which allows more 
requesters to log on simultaneously 
to OS/2 LAN Server 1.3. It also im¬ 
proves the speed of some of the 
more time-consuming network ad¬ 
ministration options when they are 
run on a busy network. The reliabil¬ 
ity of NETLOGON service has also 
improved. On networks where some 
of the servers have problems with 
their system clock, LAN Server 1.3 
now replicates more efficiently. 

This is because the system clock is 
now synchronized with the domain 
controller at server startup. OS/2 
and DOS requesters synchronize 
their clocks at logon time. 

Minor changes have been made to 
other network services. For exam¬ 
ple, the PC DOS RIPL (remote 
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boot) service now has increased net¬ 
work security. Periodic improve¬ 
ments will be made to the network 
services, and new services may be 
written in the future for special pur¬ 
pose tasks. 

Network Utilities 

The most visible part of the net¬ 
work, and the part that most obvi¬ 
ously distinguishes one network 
product from one another, network 
utilities include most commands 
that a user types in at the OS/2 
prompt. Examples are NET USE, 
LOGON, and AT. Network utilities 
also include the network full-screen 
interface and UPM menus. The net¬ 
work utilities are transient, and exe¬ 
cute for only brief periods. To 
maintain compatibility with previ¬ 
ous releases and to ease migration, 
the format of existing LAN Server 
1.0 commands was not dramatically 
altered for LAN Server 1.2 and 1.3. 
However, many new commands 
were added. 

While the basic structure of the 
LAN Server 1.3 menus has not 
changed, the usability of many op¬ 
tions was improved, in response to 
customer requests. Among the most 
noticeable changes are improve¬ 
ments to simplify managing long 
lists of data through the menus. Be¬ 
cause LAN Server 1.3 domains are 
expected to be larger than those of 
previous versions, it was important 
to improve support for lengthy net¬ 
work administration tasks. 

The AT command, which is used to 
schedule tasks for future execution 
on a server, was changed to allow 
those tasks to execute with network 
administrator privilege. For security 
reasons, this required that the com¬ 
mand be scheduled by a network ad¬ 
ministrator. Some of the more 
visible command changes were 


made to LOGON and LOGOFF, 
which are now noticeably faster on 
large, heavily loaded networks. 

One of the most important of the 
network utilities is the network mes¬ 
sages and help support. Many mes¬ 
sages were added, and help texts 
were improved to simplify the task 
of analyzing potential problems. 

Redirector 

Considered by some an extension of 
the base operating system, the 
redirector handles rerouting of oper¬ 
ating system requests destined for 
network devices. When an attempt 
is made to access a file that is lo¬ 
cated on a network drive, the 
redirector intercepts and reformats 
the request, then sends it to 
NETBIOS for transmission across 
the network. An extremely complex 
and delicate piece of code, the 
redirector was significantly modi¬ 
fied for LAN Server 1.2. This was 
done to support a new class of 
server message blocks, as well as to 
support the new OS/2 high perfor¬ 
mance file system. LAN Server 1.3 
was changed to better support ac¬ 
cess to PCLP servers. Its behavior 
is improved when out of resources, 
and when unexpected network hard¬ 
ware errors are encountered. This 
portion of the network is largely in¬ 
visible, and rarely needs to be con¬ 
sidered except for a few 
configuration settings in the 
IBMLAN.INI file. 

Two changes have been made to the 
redirector heuristic options 
(WRKHEURISTICs). A user can 
now choose whether the redirector 
should ignore requests by an appli¬ 
cation to flush data to disk immedi¬ 
ately. Users may choose this option 
if running an application that unnec¬ 
essarily ties up network bandwidth 
by frequently issuing DosBufReset 


calls. The other new heuristic al¬ 
lows more flexibility for DOS print 
buffer timeouts. 

While usability considerations for 
the redirector are few, changes were 
made to improve the messages that 
it generates. Messages and helps 
are now available when unexpected 
NETBIOS errors are generated. 

Network API support 

The network API support provides 
an intermediate layer between the 
network utilities (and services) and 
the redirector. It includes support 
for the many network function calls 
that applications (including the 
LAN Server code itself) use. Over 
100 API calls in 24 categories are 
documented and available for use 
by programmers. Because of critical 
compatibility considerations, the for¬ 
mat of the calls has not changed 
from LAN Server 1.2 to 1.3. 

Changes to this layer, except for per¬ 
formance changes, are largely invisi¬ 
ble to users. 

NETBIOS and Lower-Level 
Network Protocol Support 

Composed of many cooperating lay¬ 
ers, the lower level network proto¬ 
col support includes NETBIOS and 
the 802.2 layer. For OS/2 machines 
running on Ethernet (and in the fu¬ 
ture for those running on other 
NDIS compatible network adapters) 
it also includes a protocol manager. 

It also includes the communication 
manager configuration features used 
for NETBIOS and 802.2 support. 
Discussions of specific changes to 
these layers is beyond the scope of 
this article. 

Base Operating System 

Changes to the base operating sys¬ 
tem (OS/2 1.3) are not discussed 
here, but because some changes sig¬ 
nificantly affect network perfor- 
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mance, they will be described. The 
base operating system provides cru¬ 
cial features such as the print 
spooler and manager, presentation 
manager (PM) and traditional oper¬ 
ating system features. The new 
spooler is significantly faster and 
easier to manage across the net¬ 
work. Among the most important of 
the operating system features are 
memory management and program 
loading, and both have been im¬ 
proved for network applications run¬ 
ning on OS/2 1.3. Applications 
running on redirector drives no 
longer swap as heavily when physi¬ 
cal memory is overcommitted, and 
programs load more quickly on redi¬ 
rected drives. A side effect of the 
improved memory management is 
that servers and requesters can often 
run in slightly less physical memory 
than they did under OS/2 1.2. 

DOS LAN Requesters 

Because most users of IBM network 
products operate DOS requesters, 
improvements to the DOS Re¬ 
quester code are very visible. Struc¬ 
tured like the OS/2 LAN products, 
the DOS LAN Requester is actually 
a collection of many cooperating 
layers. Additional DOS command 
options include a NET STOP com¬ 
mand that removes most of DOS 
LAN Requester from memory when 
network access is no longer needed. 
This is important in many memory- 
constrained DOS systems. 

An option to prompt the user for a 
password has been added to NET 
LOGON. The API support has been 
increased so that Microsoft Win¬ 
dows 3.0 can access the network 
API from protect mode. This allows 
many network functions, such as 
using network resources, to be avail¬ 
able from within Microsoft Win¬ 
dows. The redirector has been 
enhanced to improve performance 


on applications that do many con¬ 
flicting lock requests. 

More memory is now available 
when starting programs from the ap¬ 
plication selector. 

With LAN Server 1.3, IBM is in¬ 
cluding DOS LAN Requester as 
well as DOS LAN Support program 
version 1.2. Included in this new 
version of LAN Support program 
are device drivers for some popular 
Ethernet network adapters. Helps 
have also been improved for the 
DOS LAN Requester. 

An Improved LAN Server 

With the customer requirements for 
ever faster and more reliable net¬ 
work products, network software de¬ 
signers are constantly pushed to 
improve their products. With the re¬ 
lease of OS/2 LAN Server 1.3, IBM 
increased performance, added new 
features and improved reliability. 
These changes should help make 
the LAN Server even more suitable 
for general-purpose networks, as 
well as for the customer-designed. 


custom-programmed networks that 
are now beginning to appear. 
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IBM Windows 
Connection 2.0: 

A Graphical Look 
for Host 
Applications 

Kevin Maier 
IBM Corporation 
Boca Raton , Florida 

IBM Windows Connection is an 
application that enables users to 
view host sessions and operate 
them from the graphical environ¬ 
ment created by Microsoft 
Windows. 

Graphical environments for per¬ 
sonal systems have become very 
popular. This is evidenced by the 
soaring popularity of several graphi¬ 
cal user interfaces (GUIs) such as 
OS/2 Presentation Manager and 
Microsoft Windows. GUIs are popu¬ 
lar because they give users better 
control of the system, and because 
they create more productive environ¬ 
ments for appropriate applications. 
Hundreds of applications have been 
developed for GUIs, and growth is 
expected to continue. 

New applications are being devel¬ 
oped to replace virtually all aspects 
of computer-based interfaces. Also, 
users are looking for additional 
graphical applications to run on 
their systems. 

One area in particular is the host 
mainframe environment typically 
used within large corporations. For 
many years, large and bulky dedi¬ 
cated terminals have been replaced 
with personal computer systems by 
adding both an adapter card to estab¬ 
lish the physical connection and em¬ 
ulation software to drive it. 


Function and performance have con¬ 
tinued to increase in this application 
area. Within OS/2 Extended Edi¬ 
tion, the Communications Manager 
can place multiple host sessions in 
windows on the screen, allowing 
multiple sessions to be operated and 
viewed. There are, however, some 
limitations with the user interface. 

IBM has seen the need to supply 
users of Microsoft Windows with 
this capability of having host ses¬ 
sions within windows and having 
additional function. As a result, 

IBM has developed Windows 
Connection. 

The 1.0 version of Windows Con¬ 
nection allowed users of Microsoft 
Windows 2.X to access their host 
sessions without leaving the Win¬ 
dows environment. Windows Con¬ 
nection 1.0 permitted only 3270 
emulation, so users of 5250 termi¬ 
nals were left out. With the recent 
announcement of Windows Connec¬ 
tion 2.0, 5250 users with Microsoft 
Windows 3.0 can now have a graph¬ 
ical interface to their host sessions. 

Highlights of Windows 
Connection 2.0 

Windows Connection 2.0 is a 
Microsoft Windows 3.0 application 
developed by IBM. It allows host 
sessions to be viewed and operated 
from the graphical environment cre¬ 
ated by Windows. It can interact 
with other Windows applications 
through Dynamic Data Exchange 
(DDE) and the Windows clipboard. 

Windows Connection 2.0 also en¬ 
hances the user interface, making 
many functions, such as file trans¬ 
fer, easy to use. A keyboard 
remapper is also included. 

Windows Connection, however, is 
not a terminal emulator. It requires 


the availability of an emulator that 
has a High-Level Language Applica 
tion Programming Interface 
(HLLAPI). Windows Connection 
uses HLLAPI to access the host and 
to provide host functions. Windows 
Connection also allows for an im¬ 
proved migration path to OS/2 Ex¬ 
tended Edition. 

Windows Connection runs on any 
80286, 80386, 80386 SX, or 80486- 
based system having at least one 
megabyte of memory, a graphics dis 
play, a mouse, and an enhanced or 
AT-style keyboard. Windows Con¬ 
nection requires DOS 3.30 or 4.00, 
Microsoft Windows Version 3.0, 
and the appropriate hardware 
adapter and host communications 
program. 

(Note: The amount of memory used 
with Windows 3.0 varies. In most 
cases, two to four megabytes of 
memory gives acceptable perfor¬ 
mance. The minimum recom¬ 
mended memory yields minimum 
performance.) 

IBM supports the following emula¬ 
tion programs: 

• IBM PC 3270 Emulation Pro¬ 
gram Entry Level version 1.22 

• IBM Personal Communica¬ 
tions/3270 (with the latest correc¬ 
tive service diskette) 

• IBM AS/400 PC Support for 
Release 3 

Using the host communications pro¬ 
gram, the following communication 
protocols are supported: 

• Synchronous Data Link Control 
(SDLC) 

• Distributed Function Terminal 
(DFT) mode 

• Control Unit Terminal (CUT) 
mode 
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• Asynchronous 

• IEEE 802.2 

— IBM Token-Ring 

— IBM PC Network 

— Ethernet (requires LAN Sup¬ 
port Program 1.2) 

• Twin-Axial 5250 (AS/400) 

Windows Connection is installed by 
using the File Manager from Win¬ 
dows and executing the 
1NSTALL.EXE program on the 
Windows Connection diskette. This 
allows Windows Connection to add 
the necessary information to the 
Windows initialization file 
(WIN.INI), set up the Windows 
Connection group, and add the re¬ 
quired program items (Windows 
Connection and the keyboard 
remapper). 

Features of Windows 
Connection 2.0 

Windows Connection has an im¬ 
proved file transfer interface. File 
transfer is handled via a drop-down 
menu and a dialog box for 
filenames and transfer options. Win¬ 
dows Connection also supports mul¬ 
tiple file (batch) transfers and can 
automatically generate the target 
filename by using templates that 
can be customized by the user. Both 
short and long dialog boxes are 
available, and VM and MVS ex¬ 
tended options are supported. This 
greatly simplifies file transfer for 
the user. For AS/400™ users, file 
transfer is done using the virtual 
drive support within PC Support. 
These users can employ the system 
utilities to copy files from one drive 
path to another. 

Windows Connection also allows 
the user to customize each session 
independently. The session colors 
are easily changed within a drop¬ 



down menu showing a palette of 
selectable colors and display attri¬ 
butes. Screen fonts can be changed 
within a drop-down menu that 
shows a list of the available type¬ 
faces, point sizes, and a sample text 
string preview. The session title can 
be modified in the same manner, al¬ 
lowing the user to select a short or 
long session name, subtitle, session 
dimensions, session type, and an op¬ 
tional separator character. 


Other functional enhancements in¬ 
clude hotspots and the pop pad. 

Hotspots allow the mouse to be 
used for entry of PF keys, numeric 
topic entry, text string entry, or 
custom macro execution. Hotspots 
are defined by the user from a drop¬ 
down dialog box showing the avail¬ 
able options. The user can enable 
desired options by placing the 
mouse pointer on the appropriate op¬ 
tion and clicking the left mouse but- 
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ton. This selection is a toggle; click¬ 
ing the left mouse button again will 
disable the function. 

The pop pad consists of two groups 
of eight functions each that aid the 
user in performing common emula¬ 
tor functions. For example, a 3270 
keyboard has special keys, such as 
Clear, PA1, PA2, and so forth. 

These keys do not exist on a PC- 
style keyboard. With emulation pro¬ 
grams, multiple key sequences, such 
as Alt-Esc, Ctrl-F9, execute these 
functions. The pop pad is designed 
to enhance the user interface for 
these needed functions. 

The pop pad is activated by clicking 
the right mouse button with the 
pointer in an active window. The 
pop pad is then displayed, and the 
function can be selected. The pop 
pad has default settings that are usu¬ 
ally adequate for most users, but are 
easily changed by using the key¬ 
board remapper program. When a 
user points to the desired function 
button on the pop pad and clicks the 
left mouse button, the function is 
performed by Windows Connection, 
and the pop pad is removed from 
the window. 

Windows Connection also allows 
copy and paste functions to and 
from the Windows clipboard. When 
marking text using the mouse, Win¬ 
dows Connection generates a re¬ 
verse video preview of the marked 
area. This allows text information to 
be transferred easily to and from 
other Windows applications such as 
word processors. Because of the sin¬ 
gle-screen limitation of the host, 
however, only one full screen of 
text can be copied to the clipboard 


at a time. Also, when pasting text to 
a host session, the user is limited by 
the definition of fields on the screen 
- that is, the user cannot paste text 
into a protected field. 

Windows Connection also has a full 
Dynamic Data Exchange (DDE) in¬ 
terface to Windows. It conforms to 
the full Windows 3.0 protocol. This 
allows Windows Connection to 
function as a DDE server to other 
Windows applications such as 
Microsoft Excel and Word for Win¬ 
dows. Full two-way communication 
and data exchange are allowed. This 
creates a strong foundation for 
custom application development. 



Windows Connection has 
a full Dynamic Data 
Exchange interface to 
Windows. 


Session management and multi- 
session management viewing are 
also provided. These allow func¬ 
tions such as Auto-logon, opening 
and closing of session windows, 
and linking a macro to a session. 
The user can also save preferred 
configurations that enable Windows 
Connection to open the host ses¬ 
sions as active windows or as icons. 
A “jump” function is available that 
permits the user to select between 
active sessions. 

The Key Mapper program allows 
the keyboard and pop pad defini¬ 


tions to be customized easily. It gen¬ 
erates a graphic representation of 
the keyboard in a window. With a 
simple point-and-select interface, 
the user can use the mouse to query 
the current key assignments and to 
change them. The pop pad is also 
shown graphically on the screen, 
and changes are made in the same 
manner using the mouse. The Key 
Mapper also aids the user in macro 
generation. Specific functions are 
provided for both 3270 and 5250 
emulations, and a help option is 
available. Changes can be saved eas¬ 
ily in a key map file and can be re¬ 
loaded without closing Windows 
Connection. 

Summary 

Windows Connection is a simple ap¬ 
plication that allows the user to ac¬ 
cess the host from a graphical 
environment while enhancing much 
of the available function. This, cou¬ 
pled with the capability of future ap¬ 
plication expansion and ease-of-use, 
makes Windows Connection a must 
for any Windows user who needs 
host connectivity. 
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SNA Definitions 
for 3270 
Emulators - 
Part II 

William J. Wen 
Houston, Texas 

This is the second part of an arti¬ 
cle begun in our last issue. Here, 
we will apply the concepts shown 
in the first part to specific connec¬ 
tivity scenarios. We define six sce¬ 
narios: a combination of two PC 
3270 emulators communicating 
via the Token Ring Network (TRN) 
through three types of controller 
gateways. In these examples, we 
explicitly point out how the vari¬ 
ous parameters relate to one 
another. 

In part one, I provided the neces¬ 
sary background information to re¬ 
late the addressing scheme from the 
emulators through the controller 
gateway to VTAM^. With this infor¬ 
mation, we now will show six sam¬ 
ple configurations that result from 
two 3270 emulators communicating 
through three different types of 
TRN controller gateways. 

Token Ring Network 
Controller Gateways 

There are three types of TRN con¬ 
troller gateways. One type is the 
local 3174 controller gateway. 3174 
models OIL, 11L, 12L, 21L, and 
22L with the TRN 3270 gateway 
feature can be configured for this 
gateway. PUs going through the 
3174-x 1L gateway appear to 


VTAM as PUs daisy-chained on a 
channel with the xlL gateway. 

The second type is the remote 3174 
controller gateway. Ten 3174 mod¬ 
els can be configured as remote con¬ 
troller gateways: 3174 models 01R, 
HR, 02R, 12R, 21R, 51R, 61R, 

52R, 62R, and 90R with the remote 
TRN 3270 gateway feature. PUs 
going through a remote 3174 con¬ 
troller gateway appear to VTAM as 
PUs multidropped connected to a 
nonswitched SDLC line. 

The third type is the 37XX commu¬ 
nications controller gateway run¬ 
ning the Network Control Program 
(NCP). Three different communica¬ 
tions controllers may be configured 
for this gateway role: the 3720, 
3725, and the 3745 with the Token 
Ring Interface Coupler (TIC), and 
running NCP Version 4 Release 2 
or higher. PUs going through a 
NCP gateway appear to VTAM as 
PUs connected to switched lines. 

Some conventions are used in the 
configuration examples on the fol¬ 
lowing pages (Example #01 through 
Example #06). Each example has 
three columns: 

• Left column is for definitions 
from the specific emulator 

• Center column is for definitions 
of the specific controller gateway 

• Right column is for VTAM 
definitions 

The description for a field some¬ 
times stretches beyond the bounds 
of its designated column. For exam¬ 
ple, with OS23270 LU definitions, 
the “LU local address (nau address) 
...|kk]” definitions are long enough 


to have stretched into the center col¬ 
umn. Whenever possible, the exam¬ 
ples used the same field names as in 
the actual configuration. Some field 
names are not configurable or are 
implied; I have enclosed such field 
names in parentheses. The “Destina¬ 
tion Address” field is the exact field 
name displayed when customizing 
OS23270. On the other hand, “(SAP 
ID of OS23270)” is the field name 
coded into OS23270 and cannot be 
customized by the operator. 

The lines between columns show 
matching fields. How lines termi¬ 
nate have specific meanings. When 
a line breaks with an arrow, the 
field it points to may be changed. 
When the line breaks without an 
arrow, the field it points to cannot 
be changed. 

When viewing 3174 customization 
in TEST mode, you will see the 
screens in the same sequence as in 
Figures 1 through 8. I will refer to 
specific customization questions in 
the examples. (Part one of this arti¬ 
cle referred to these figures as Z401 
through Z408.) 

ABOUT THE AUTHOR 

William J. Wen received a 
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Example #01: OS23270 through a Local 3174 Gateway 


OS2370 3174-OIL 

(connected on Channel A) 


(* * 01 ) 

(* 02 ) 

(*03) 
(*04) 


(*05) 


Destination Address 

XXXX XXXX XXXX «.-► Q900 

(Destination SAP ID) 

04 - (SAP ID of 3174) 

(SAP ID of 0S23270)- 

(TRN address) *_ 

S@ Ring@ SAP@ 

nn XXXX XXXX XXXX 04 

Q940 


Specify SDLC/IBM Token-Ring Network Data 


(*06) LU local address (NAU address) .. [kk] 


VTAM 


T 

0 

PUL12 PU CUADDR=Ann 

LUL12kk LU L0CADDR=kk 


*01 The Destination Address in OS23270 needs to match the TRN address of the 3174, which is in the 3174 
customization Question 900 (Figure 5). OS23270 allows the full 12 digits of the destination address to be 
specified. 

*02 The DSAP ID in OS23270 is coded as 04 and may not be customized. This SAP ID matches the 3174 SAP 
ID. Neither field may be modified. 

*03 The SAP@ field in the 3174 Question 940 (Figure 6) needs to match the SAP ID of OS23270, which is 04. 

*04 The TRN address of the PC running the 3270 emulator needs to be defined in the Ring@ field of 3174 
Customization Question 940 (Figure 6). Although it is possible to input the Universal Administered Address 
(UAA) of the PC TRN card in the Ring@ field of Q940, it is recommended that the PC TRN address be a Lo¬ 
cally Administered Address (LAA) instead. Each TRN card has the UAA coded on the card and is unique, as 
each UAA has to be registered with a central authority. The LAA assigned by the user during installation of the 
TRN card and needs to be unique in a specific TRN installation. If you specify the UAA of the PC TRN card in 
the 3174 and later needed to swap out the PC TRN card, your network administrator will need to bring the 3174 
offline, recustomize 3174 questions, and re-IML (Initial Machine Load). This set of operations would disrupt the 
work environment for all other devices accessing the 3174 controller gateway. 

*05 Because this is a local 3174 controller gateway, the PUs going through the gateway appear as local devices 
daisy-chained off a specific channel. Consequently, the TRN address of a downstream PU is associated to the 
CUADDR= field of a PU definition in VTAM (through the 3174 Q940). 

*06 How the LU local addresses are associated to specific sessions on the OS23270 side is different from the 
DOS 3270 emulators. The DOS 3270 emulators use positional dependence. OS23270 allows the operator to 
specify what local address is associated to a display session. 
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Example #02: PCOM3270 through a Local 3174 Gateway 


PCOM3270 


3174-OIL VTAM 

(connected on Channel A) 


(*01) Destination address 

XXXX XXXX XXXX -► Q900 

(*02) (Remote SAP) 

04 «- (SAP ID of 3174) 

(*03) (SAP ID of PC0M3270) - 

(*04) (TRN address)*— 

S@ Ring@ SAP® 

nn XXXX XXXX XXXX 04 


(*05) 


Q940 


LU address/ 
LT number 
(optional) 

(*06) [LU kk] 


T 

0 

PUL17 PU CUADDR=Ann 


LUL17kk LU L0CADDR=kk 


*01 The destination address in PCOM3270 needs to match the TRN address of the 3174, which is in 3174 
customization Question 900 (Figure 5). PCOM3270 allows the full 12 digits of the destination address to be 
specified. 

*02 The SAP ID of the controller gateway is specified in the Remote SAP. The value of 04 needs to be spec¬ 
ified for this field, as the SNA controller TRN gateways (3174, 3720, 3725, and 3745) all use a 04 SAP ID. 

*03 The SAP@ field in the 3174 Question 940 (Figure 6) needs to match the SAP ID of PCOM3270, which 
is 04. 

*04 See item *04 in Example #01. 

*05 See item *05 in Example #01. 

*06 The LU local addresses are associated differently from specific sessions on the PCOM3270 side to other 
DOS 3270 emulators. Most DOS 3270 emulators use positional dependence. PCOM3270 allows the operator 
to specify what specific local address is associated with a display session. Specifying values for the LU ad¬ 
dress is optional under PCOM3270. If values are not specified, then the default of the first session is 
LOCADDR=02, the next is LOCADDR=03, and so on. 
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Example #03: OS23270 through a Remote 3174 Gateway 


OS3270 3174-XXR VTAM 

(connected to line=023) 

(* *01) Destination Address 

XXXX XXXX XXXX ^-► Q900 

(*02) (Destination SAP ID) 

04 _ (SAP ID of 3174) 

(*03) (SAP ID of 0S23270)- 

(*04) (TRN address) <.-. 

i 1 

S@ Ring@ SAP@ T 

nn XXXX XXXX XXXX 04 0 


Q940 


(*05) 





DEFLINE 

LINE 

ADDRESS=023 






-* PUR12 

PU 

ADDR-nn 


Sped fy 

SDLC/IBM 

Token-Ring Network Data 




(*06) 

LU loca 

1 address 

(NAU address), 

,.[kk] «— 

— LUR12kk 

LU 

L0CADDR=kk 


*01-*04 These matching fields are the same as a local 3174 controller gateway. Refer to items *01 through 
*04 of Example #01 for information on items *01 through *04 of this configuration, respectively. 

*05 Because this is a remote 3174 controller gateway, the downstream PUs going through this gateway ap¬ 
pear as remote PUs multidropped off a SDLC nonswitched line. So, the TRN address of a downstream PU is 
associated with the ADDR= field of a PU definition in VTAM (through 3174 Question 940). 

*06 This matching field is associated in the same way as a local 3174 controller gateway. Refer to item *06 
of Example #01 for information on this item. 
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Example #04: PCOM3270 through a Remote 3174 Gateway 


PCOM3270 3174-XXR 

(connected on line=023) 


VTAM 


(* * 01 ) 

(* 02 ) 

(*03) 

(*04) 


(*05) 


Destination Address 

XXXX XXXX XXXX «-► Q900 

(Remote SAP) 

04 *- (SAP ID of 3174) 

(SAP ID of PC0M3270) _ 

(TRN address) <•-^ 

S@ Ring@ SAP@ T 

nn XXXX XXXX XXXX 04 0 

Q940 

DEFLINE LINE 

-► PUR17 PU 


ADDRESS-023 

ADDR=nn 


LU address/ : 

LT number : 

(optional) : 

(*06) [LU kk] «-► LUR17kk LU L0CADDR=kk 


*01-*04 These matching fields are the same as with a local 3174 controller gateway. Refer to items *01 
through *04 of Example #02 for information on items *01 through *04 of this configuration, respectively. 

*05 See item *05 in Example #03. 

*06 This matching field is same as a local 3174 controller gateway. Refer to item *06 of Example #02 for 
information on this item. 
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Example #05: OS23270 through a 37XX NCP Gateway 



OS23270 

37XX (NCP) 

VTAM 



GROUP ECLTYPE-PHYSICAL 

LINE ADDRESS-(xxx,FULL) 

(*01) 

Destination Address 

4000 XYYY YYYY % 

r 1OfAO0=4000YYYYYYYY 

(*02) 

(*03) 


PORTAnn-tt . 

(Destination SAP ID 




04 _ (SAP ID of 37XX TIC) 


GROUP ECLTYPE-LOGICAL 
(if under the LINE macro) 

(*04) CALL-INOUT 

CALL-OUT 


(then the following block) 
(skip block otherwise) 


(*05) (TRN address) 


(*06) (SAP ID of 0S23270) 


PATH DIALN0-U044000XYYYYYYY 

t_ 


(*07) (Program ID of 0S23270)- 

(*08) Node ID (in hex) 

nnnnn «_ 

Specify SDLC/IBM Token Ring Network Data 

(*09) LU local address (NAU address)..[kk] «— 


SW1 VBUILD Type-SWNET 

PUS12 PU IDBLK-05D 

_ ► IDNUM-nnnnn 

LUL12kk LU LOCADDR-kk 
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*01 The destination address in OS23270 needs to match the TRN address of the 37XX TIC, which is defined 
in the LOCADD= field under the Physical Group for the specific TIC (these definitions are in NCP). 

*02 One TIC may have up to four TRN connections; the four TRN connections are distinguished by port ad¬ 
dresses. A port address is the PORTADD= field under the Physical Group in NCP. Each port on a TIC has a 
unique TRN address (LAA), and the same 37XX may have multiple ports connected to the same TRN or to 
separate TRNs. VTAM does not need to know the TRN address of a specific port, as VTAM communicates 
through a port address, and NCP translates the port address to a TRN address. To communicate to VTAM, 
the downstream PU, in turn, needs to know only the 37XX TIC TRN address, not the port address. 

*03 The Destination SAP ID in OS23270 needs to match the SAP ID of the 37XX TIC, which is 04. The op¬ 
erator cannot customize the destination SAP ID in OS23270. 

*04 There is an option in the LINE macro under a Logical Group in NCP that defines whether VTAM may 
initiate contact with a downstream PU. Specifying CALL=IN indicates only that the downstream PU can initi¬ 
ate contact; specifying CALL=INOUT indicates that either the downstream PU or VTAM can initiate contact. 

*05-06 These two sets of matching fields apply only when the NCP lines going through the TIC are for host- 
initiated contact. Keep in mind that downstream PUs on the TRN appear to the host as switched PUs. The 
DIALNO= field under the PATH macro define a "phone number" that VTAM can use to contact the down¬ 
stream PU. The DIALNO= field includes information on which TIC address to go through, what destination 
SAP ID to establish a link with (the destination SAP would be the source SAP ID of the 3270 emulator), and 
the TRN address of the downstream PU. For a downstream PU-initiated contact, the fields in *05 and *06 do 
not need to match, as the 37XX dynamically saves the downstream PU’s SAP ID and TRN address. 

*07 The IDBLK= under a PU definition in a VTAM Switched Major Node needs to match the program ID of 
OS23270, which is X’05D\ Both the IDBLK= and the IDNUM= fields must match the XID from the down¬ 
stream PU or VTAM will reject the call. 

*08 The IDNUM= under a PU definition in a VTAM Switched Major Node (the same PU definition with the 
matching IDBLK= field) needs to match the “Node ID (in hex)” field in OS23270. When a downstream PU 
initiates contact with the host, it sends its program ID together with its PUID (in the form of an XID) to 
VTAM. This needs to match the IDBLK= and IDNUM= fields, respectively, under a specific PU definition 
found in a VTAM Switched Major Node. 

*09 How LU local addresses are associated to specific sessions on the OS23270 side is different from the 
DOS 3270 emulators. The DOS 3270 emulators use positional dependence. OS23270 allows the operator to 
specify what local address is associated to a display session. 
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Example #06: PCOM3270 through a 37XX NCP Gateway 


PCOM3270 37XX (NCP) VTAM 


GROUP ECLTYPE=PHYSICAL 
LINE ADDRESS=(xxx.FULL) 

-► L0CADD=4000XYYYYYYY 

P0RTADD=tt <,- 

(SAP ID of 37XX TIC) 

GROUP ECLTYPE=LOGICAL 

(if under the LINE macro) 

(*04) CALL=INOUT 

CALL=0UT 


(then the following block) 
(skip block otherwise) 


(*05) (TRN address) m - 

(*06) (SAP ID of PC0M3270) 


PATH DIALN0=tt044000XYYYYYYY 

t_ 


SW1 VBUILD Type=SWNET 

(*07) BLOCK ID [ZZZ] «-► PUS17 PU IDBLK=zzz 

(*08) Physical Unit ID : 

[nnnnn] «-► IDNUM=nnnnn 

LU address/ : 

LT number : 

(optional) : 

(*09) [LU kk] *-► LUS17kk LU LOCADDR=kk 


(*01) Destination Address 
4000 XYYY YYYY *- 

(* 02 ) 

(*03) Remote SAP 

04 <■- 
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*01 The Destination Address in PCOM3270 needs to match the TRN address of the 37XX TIC, which is in 
the LOCADD= field under the Physical Group for the specific TIC (these definitions are in NCP). 

*02 See item *02 in Example #05. 

*03 The Remote SAP in PCOM3270 needs to match the SAP ID of the 37XX TIC, which is 04. 

*04 See item *04 in Example #05. 

*05-*06 See items *05-*06 in Example #05. 

*07 The IDBLK= under a PU definition in a VTAM Switched Major Node needs to match the "Block ID" 
field in PCOM3270. PCOM3270 is different from any other IBM 3270 emulator because it allows the user to 
specify the program ID. 

*08 The IDNUM= field under a PU definition in a VTAM Switched Major Node (the same PU definition that 
has the matching IDBLK= field) needs to match the "Physical Unit ID" field in PCOM3270. When a down¬ 
stream PU initiates contact with the host, it sends its program ID with its PUID (in the form of an XID) to 
VTAM, which would need to match respectively the IDBLK= and IDNUM= fields under a specific PU defini¬ 
tion found in a VTAM Switched Major Node. 

*09 How the LU local addresses are associated to specific sessions on the PCOM3270 side is different from 
other DOS 3270 emulators use positional dependence. PCOM3270 allows the operator to specify what spe¬ 
cific local address is associated display session. Specifying values for the LU address is optional under 
PCOM3270. If values are omitted, then the default is the first session in LOCADDR=02, the next 
LOCADDR=03, and so on. 
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3174 Test Menu 

Select 

test; 

press 

ENTER 


Test 


Description 


0 


Terminal check 


1 


Display event logs and response time log 


2 


Display configuration panels 


3 


Display status summary 


4 


Reset logs and cable errors 


5 


Display vital data 


6 


Display storage 


7 


Color convergence 


8 


Extended functions and program symbols 


9 


Token ring tests 


10 


Port wrap tests 


11 


Trace control 


A 


A1erts 


D,n 


Dump device on port n (n-0-31) 

Select 

=—> 

2 


PF: 3=Quit 




Figure 1. First Screen in TEST Mode 


_Configuration Menu_ 

Select Option; press ENTER 
Option Description 

1 Hardware configuration 

2 Configuration questions 

3,n Printer authorization matrix for entry n (n=l-31) 


To go directly to other tests, enter: /Test,Option 
Select — > 2 

PF: 3=Quit 12=Test Menu 

Figure 2. TEST Mode after Selecting “Display Configuration Panels” 
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Model / Attach 

099 - 3174 

CONTROLLER GATEWAY SETUP 

100 - OIL 


101 - 5 


Select -—> 


PF: 3-Quit 

8=Fwd 12-Test Menu 


Figure 3. Controller Attachment Information 




Local 

(SNA) 




104 

- 40 

105 - 5F 

108 - 

23F5803 

116 - 

1 

121 

- 01 

125 - 01000100 

127 - 

0 0 



132 

- 0 0 0 0 

136 - 1 1 1 1 

137 - 

0 0 0 0 

138 - 

0 

141 

- A 

165 -0 

166 - 

B 



173 

- 00000001 

175 - 





213 

- 0 

215 - 00000 

220 - 

2 



222 

- 1 

223 - 10 

224 - 

2 

225 - 

4 

Select —> 






PF: 

3-Quit 

7-Back 

8-Fwd 

12-Test 

Menu 



Figure 4. Local SNA Definitions 


Personal Systems/Issue 2, 1991 










70 


_ Token Ring Gateway_ 

900 - 4000 0154 1031 905 - 1 908 - CTL640 


Select —> 

PF: 3-Quit 7-Back 8=Fwd 12-Test Menu 


Figure 5. Token Ring Definitions for this Gateway 


940: Ring Address Assignment 


s@ 


Ri ng@ 


SAP@ 

T 

s@ 


Ri ng@ 


SAP@ 

T 

40 

4000 

0154 

1031 

04 








41 

4000 

1011 

4564 

04 

0 

42 

4000 

5612 

5482 

04 

0 

43 

4000 

4011 

4642 

04 

0 

44 

4000 

4546 

6844 

04 

0 

45 

4000 

2012 

1654 

04 

0 

46 

4000 

4168 

5364 

08 

0 

47 

4000 

3390 

1348 

08 

0 

48 

4000 

1684 

4618 

04 

0 

49 

4000 

1000 

4869 

08 

1 

4A 
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Figure 6. Definitions of Downstream PUs 
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941: Ring Address Definition_ 
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Figure 7. I-Frame Definitions for Downstream PUs 
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Little Solutions 


We invite you to share your “little 
solutions” in this column. Send them 
to us in care of the editor. 


Cursor Speedup 

On IBM PS/2 systems, there's an 
option on the reference diskette to 
control the speed of the cursor 
when holding down the arrow keys. 
Setting the cursor speed to “fast" is 
ideal for a person experienced with 
an application because it makes 
movement through a document 
faster and reduces the delay be¬ 
tween operations. 

Simply insert the reference diskette, 
re-boot your system, and select the 
“Set Features" option. At the next 
menu level, select “Keyboard 
Speed," and then select “Fast." 

Press ESC until the system tells you 
to reboot. This change will be saved 
even after power-off. - Lincoln 
Fetcher. Northwest Airlines, St. 

Paul, Minnesota. 

80386 Memory Expansion 
Option 

There is some confusion about the 
memory returned upon Power On 
Self Test (POST) whenever an 
80386 Memory Expansion Option is 
installed on a PS/2. If, for example, 
you have 8 MB on the system board 
and 8 MB on the 80386 Memory 
Expansion Option, why does the 
POST show only 8 MB instead of 
16 MB? The reason is this: 



PS/2 Micro Channel architecture 
can initialize adapters in two differ¬ 
ent ways. Most adapters use the 
ADF file on the reference diskette 
or a driver that comes with the 
adapter. The SETUP program initial¬ 
izes these adapters before POST is 
run. 

The Enhanced 80386 Memory Ex¬ 
pansion Option, a more complicated 
adapter, uses an initialization pro¬ 
gram that runs after POST. This 
initialization program stores infor¬ 
mation in track 0 of the fixed disk. 
Or, if booting from diskette, a 
special device driver, 
DOSMEMDD.SYS, loads the neces¬ 
sary initialization program. Upon 
power-on, POST checks the hard¬ 
ware and counts the memory it 
knows about. Because the Enhanced 
80386 Memory Option initializes 
after POST, this memory does not 
show on the POST memory count. 
After POST is complete, control is 
passed to the Enhanced 80386 Mem¬ 
ory Expansion Option’s initializa¬ 
tion program. The adapter is loaded, 
the remaining memory is then 
counted, and control is passed to the 
operating system. 

To ensure that the 80386 is in¬ 
stalled, an easy test (using DOS 
4.01) would be to install a 


VDISK.SYS of an amount larger 
than the system board memory - for 
example, 12 MB. In the 
CONFIG.SYS, add the following 
line: 

DEVICE=C:\DOS\VDISK.SYS 12288 

If the VDISK.SYS loads success¬ 
fully, the following should appear 
after restarting the system: 

VDISK version 3.40 virtual 
disk x: 

Buffer size:12288 

This verifies that the 80386 Mem¬ 
ory Expansion Option is installed 
and working. - Alissa Ross, 
Watauga, Texas 

XGA Adapter/A 

The Extended Graphics Array 
(XGA) Adapter/A is a 32- or 16-bit 
PS/2 adapter with a Base Video Ex¬ 
tension Connector (BVEC). It can 
be inserted into any 16-bit or 32-bit 
expansion slot, except for the Auxil¬ 
iary Video Extension Connector 
(AVEC) slot in a Micro Channel 
PS/2 with a 386SX, 386, or 486- 
based system unit. 

The XGA Adapter/A is often in¬ 
stalled in an inappropriate slot. In 
the PS/2 Models 55, 60, 65, 70, and 
80, it is tempting to install it into 
the slot where the 8514/A Adapter 
must reside. But this slot, known as 
the AVEC slot, will not accommo¬ 
date the XGA Adapter/A. - Jacque 
Bresnahan, Dallas 

How Much XGA VRAM? 

If you need to find out the amount 
of video RAM that’s on your PS/2 
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Model 90 or Model 95, there’s a 
fast and easy way of doing this with¬ 
out doing a physical inspection of 
the system board or the XGA 
Adapter/A. 

Use the Model 90 or Model 95 ref¬ 
erence diskette, and run Advanced 
Diagnostics by pressing CTRL A; 
you will have the option to test the 
system. At the Device Test Menu, 
select choice 6 - Advanced Func¬ 
tion General Test. At the end of this 
test, a screen appears that displays 
the amount of installed video mem¬ 
ory. — Jacque Bresnahan , Dallas 

Callback with FTTERM 

The callback security feature of 
many electronic information sys¬ 
tems may be used with IBM’s 
PC/Host File Transfer and Terminal 
Emulator Program V2.1 (FTTERM). 

Callback is the security feature for 
dialing in and entering a userid and 
password. The system drops the con¬ 
nection and performs a “callback” 
to a pre-specified telephone number. 
This assures that your userid and 
password cannot be used from any 
telephone but the one you specified. 

From the FTSETUP program, edit 
the Prefix field under Auto-Dial 
Definitions adding the number that 
you want to call. Insert the com¬ 
mand definition, enter FTTERM, 
and dial the number of the callback 
system. After the system drops the 
line, you are returned to the Auto- 
Dial Directory of FTTERM. Press 
“Enter.” You are now waiting for 
the system to call you back. After 


73 





Random Data 


receiving the CONNECT message, 
you’re on your way. 

This function cannot be automated 
because there is presently no way to 
implement it from FTHLLAPI. 

Finally, be sure to create an Auto- 
Dial profile that contains the com¬ 
mand S0=0 and activate this profile 
at the end of your session. This 
keeps the modem from answering 
the line after the session is 
complete. - David Randolph, Dallas 

SCSI Performance Tips 

These suggestions can improve per¬ 
formance in a DOS single-task 
environment. 

1. Use the utility DISK386.SYS (on 
the system reference diskette) for 
the following applications only: 

• Windows/386 below version 3.0 

• QEMM™ below version 5.0 

• 386 MAX™ below version 4.08 

• 386 MAX Professional™ below 
version 4.08 

• Workstation Program Version 
1.12 and prior versions 

A better solution to using the 
DISK386.SYS utility is to update 
the programs to their latest versions. 

If DISK386.SYS utility has been 
previously installed, and you do not 
use one of those five applications, 
then use an editor program to edit 
your CONFIG.SYS file to remove 
the statement: 

DEVICE=DISK386.SYS 


2. Install the IBM Disk Cache pro¬ 
gram (hidden file on the system ref¬ 
erence diskette). To install the IBM 
Disk Cache program: 

• Ensure that the system has IBM 
DOS Version 3.30 or 4.01 in¬ 
stalled on fixed disk C. 

• When the DOS prompt (usually 
C>) appears, insert the reference 
diskette into diskette drive A. 

• Type A:IBMCACHE and press 
Enter 

• Follow the instructions displayed. 

- Set CACHE LOCATION: (Ex¬ 
tended Memory) 

- Set disk CACHE SIZE: 
(256)KBytes 

For systems with 4 MB RAM 
or greater, the disk cache size 
could be (1000)KBytes. 

- Set CACHE PAGE SIZE: (8) 
Sectors 

3. In those cases where applica¬ 
tions will perform many short 
writes (1 byte to 2 Kbytes) to the 
hard file, applications such as com¬ 
pilers and databases (database index¬ 
ing), install a disk caching program 
that is able to do queued writes. 
Some examples of this type of disk 
cache program are: 

• Super PC Kwik by Multisoft 
Corp. 

• Vcache by Golden Bow Systems 

• Flash by Software Masters Inc. 

4. Install only one disk cache pro¬ 
gram on the system at a time. If an 
application has its own disk cache, 
remove other installed disk cache 
programs (such as IBMCACHE and 
those in performance tip number 3). 
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5. Where performance in an appli¬ 
cation that does short writes is 
needed, consider increasing the num¬ 
ber of buffers in the system. The 
number of buffers in the system is 
set with a line in the CONFIG.SYS 
file, such as BUFFERS=30. The per¬ 
formance tradeoff is that each 
buffer takes available conventional 
DOS memory space. As the number 
of buffers is increased, the amount 
of memory available to run pro¬ 
grams is decreased. 

6. Always fully populate planar 
memory to its maximum capacity 
before installing a memory expan¬ 
sion adapter. 

7. There is another utility that per¬ 
forms the same as the 
DEVICE=DISK386 mentioned in 
tip number 1. This is the 
DEVICE=GENS386.SYS utility sup¬ 
plied on the option diskette with the 
IBM CD-ROM option. For this util¬ 
ity, follow the statements in tip 
number 1. -Avery Lyford and 
George Tracy, IBM, Boca Raton, 
Florida 

EEINST, REINST, and 
EECFG 

Here’s an explanation of the correct 
use of the EEINST, REINST and 
EECFG commands in OS/2 EE 1.2. 

Use EEINST only when you need 
to interrupt the installation of OS/2 
to format partitions other than C: or 
to update your CONFIG.SYS file. 

To use EEINST correctly, do this: 

1. During the original installation 
of OS/2 EE 1.2, you are prompted 
for diskette #6. (This diskette begins 
the installation of the Extended Edi¬ 
tion portion of OS/2.) At this time, 
and this time only, you can interrupt 
the installation process by rebooting 
your machine. If you have created 


extended HPFS or FAT partitions 
and wish to format them and add 
the IFS=HPFS statement to your 
CONFIG.SYS file, or perform other 
system maintenance, reboot your 
machine now, without inserting 
diskette #6. 

2. After you have made all the de¬ 
sired changes to the system, insert 
diskette #6 into A: and type 
EEINST to start the installation of 
OS/2 EE 1.2. 

The EE component of OS/2 in¬ 
cludes User Profile Management 
(UPM), Communications Manager 
(CM), Database Manager (DBM), 
and LAN Requester. All but one of 
these components can be installed 
later with the REINST command. 
UPM is the part that cannot be in¬ 
stalled or reset with REINST. If, 
after completing the installation, 
you use the EEINST command, 
ERROR 01=UNPACK will appear. 
This indicates you are attempting to 
install UPM code onto files that al¬ 
ready exist, causing damage to exist¬ 
ing files. Once this error is received, 
REINST is no longer available. In 
order to use REINST again, the 
Base Operating System and EE por¬ 
tion must be reinstalled. (Formatting 
the drive is not neccessary.) 

Use EEINST only before installing 
files from diskette #6. Once any 
files have been installed from disk¬ 
ette #6, the REINST command must 
be used to install EE. 

Use REINST when installing por¬ 
tions of EE such as LAN Requester, 
or removing an unneeded compo¬ 
nent such as Database Manager or 
old CM configuration files. 

REINST is also used after you have 
used the Advanced Configuration 
utility of CM to add new profiles, 
such as 5250 terminal emulation or 


Remote Data Services (RDS). 
REINST is used to install the code 
or new features for the new CM pro¬ 
files that weren’t installed using the 
Basic Configuration File Services 
(BCS) and the EECFG command. 

To use REINST: 

1. Insert diskette #6 into A: and 
type REINST at the OS/2 command 
prompt. 

2. Follow the menus to install or re¬ 
move configuration files or 
components. 

EECFG is the command to create 
and install a new Basic Configura¬ 
tion Service file for communica¬ 
tions. To use EECFG: 

1. Insert diskette #6 into A: and 
type EECFG. 

2. Select the features of CM you 
need, such as LAN services. Re¬ 
mote Data Services, 3270 or 5250 
emulation, and ASCII emulation. 

EECFG can be thought of as a com¬ 
bination of Advanced Configuration 
of CM and REINST, because after 
the .CFG file is created and in¬ 
stalled into the x:\CMLIB\subdirec- 
tory, REINST is used (implicitly) to 
install the needed code. This has 
caused some confusion, because 
from here on, EECFG and REINST 
are the same. Remember, EECFG is 
used to create a new .CFG file, and 
REINST is used to add the new 
code and related features for an up¬ 
dated .CFG file. 

The EECFG and REINST com¬ 
mands are documented in Chapter 2 
of IBM Operating System/2 Ex¬ 
tended Edition Version l .2 Getting 
Started (84X0841). - Rusty Thomas, 
Fayetteville, Arkansas 
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IBM THINKable 

Bill Frank 

IBM Corporation 

Boca Raton, Florida 

THINKable is a multimedia soft¬ 
ware program for the PS/2 that 
can help therapists treat people 
suffering attention and memory 
loss as a result of injuries or 
disabilities. 

IBM always has been strongly com¬ 
mitted to making computer technol¬ 
ogy available for people with 
disabilities. State-of-the-art com¬ 
puter technology has been applied 
to a series of products to help those 
with disabilities lead independent 
lives; thus the title applied to this 
line of products - The Indepen¬ 
dence Series™. Screen Reader ™ 
helps the visually impaired to be¬ 
come computer users through voice 
communications. SpeechViewer ™ is 
a clinical tool used by speech pathol¬ 
ogists and professionals to increase 
the efficiency of speech therapy. 
PhoneCommunicaton m brings a 
wide range of telephone communica¬ 
tion options to the fingertips of peo¬ 
ple who are hearing- or speech- 
impaired. These products were de¬ 
signed to assist disabled people to 
function in the workplace and at 
home. (The Independence Series 
was described in IBM Personal Sys¬ 
tems Technical Solutions , Issue 2, 
1990, G325-5006.) 

THINKable is the latest addition to 
the Independence Series of products 
for people with disabilities. It is a 
clinical tool that can help people 
with cognitive impairments develop 
memory and improve their attention 
spans. 

Imagine trying to go through life un¬ 
able to remember people, your own 


phone number, or unable to focus 
on an issue or task before you. It 
would be frustrating and upsetting. 

Approximately 12 million individu¬ 
als suffer from memory loss as a re¬ 
sult of injury, developmental 
disabilities, substance abuse, degen¬ 
erative disease, or neurological dis¬ 
orders. Without the benefit of 
memory and a reliable attention 
span, the quality of life for all those 
people suffers. And the rest of us 
are denied the full talent, creativity 
and contributions that those 12 mil¬ 
lion people can bring to our society. 

THINKable is a software program 
that operates on the Personal Sys¬ 
tem/2 using multimedia technology. 
The program uses graphics capabil¬ 
ity to help those people with cogni¬ 
tive impairments redevelop memory 
and improve attention span through 
visual association. 

THINKable enables psychologists, 
occupational therapists, speech and 
language pathologists, and doctors 
to assist the patient or client in 
working independently. The soft¬ 


ware creates a structured environ¬ 
ment in which skills can be prac¬ 
ticed in four critical focus areas that 
relate to activities of daily living: 

• Visual attention 

• Visual discrimination 

• Visual memory 

• Visual sequential memory 

Within each focus area are four lev¬ 
els of cognitive difficulty. Thera¬ 
pists can use sample practice 
strategies provided with THINKable 
or tailor practice sessions to meet in¬ 
dividual client needs. 

Animation, photos, and natural 
voice are used to prompt users 
through practice sessions that help 
improve memory, attention, discrim¬ 
ination, and sequencing. Sample 
tasks that can be performed using 
THINKable include responding to 
specific images that appear on 
screen, matching pairs of images 
that are alike or not alike, and recall¬ 
ing the order in which images 
appear. 
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For example, voice or text, or both, 
can prompt the user to touch a tar¬ 
get image, like a chair, and on the 
next screen to identify images that 
are different, like an ice cream cone 
or flowers. 

Case Management 

THINKable uses a hierarchical 
structure consisting of elements, 
treatment components, session 
plans, and workbooks that parallel 
the way treatment professionals cur¬ 
rently plan for therapy. It includes a 
starter set of exercises for immedi¬ 
ate use. These exercises can be mod¬ 
ified for specific individuals, and 
specialized treatment plans can be 
created. Online forms make it easy 
to design exercises that offer suffi¬ 
cient cognitive difficulty to give pa¬ 
tients a feeling of accomplishment. 
Up to 14 treatment sessions can be 
planned in advance. 



Visual Attention 



Visual Memory 



Visual Discrimination 



Visual Sequential Memory 


The software also includes auto¬ 
matic data collection, analysis, and 
reporting. It enables clinicians to 
easily generate graphic and tabular 
reports for case managers, doctors, 
families, and insurers. 

Convenience Kit 

THINKable is available in a Conve¬ 
nience Kit that includes: 

• Six 3.5-inch program diskettes 

• THINKable Getting Started 

• THINKable Introduction Video¬ 
tape 

• THINKable Reference 

• Audio Capture and Playback 
Adapter (ACPA) 

• Two sets of headphones 

• One Y-cord adapter 


Supported Systems 

THINKable is supported on Per¬ 
sonal System/2 models with 80286, 
80386, or 80486 processors. 

THINKable requires a minimum of 
4 MB of free memory, a 30 MB 
fixed disk, and OS/2 Standard Edi¬ 
tion, Version 1.3. Those who plan 
to use OS/2 Extended Edition must 
have the memory and fixed-disk 
size required by that version. 

For information about purchasing 
THINKable, call 1 800 228-0752. 

THINKable is marketed by The 
Psychological Corporation, San An¬ 
tonio, Texas. 
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IBM Personal Systems Developer 

The IBM Personal Systems Developer is a quarterly publication written primarily for OS/2 application 
programmers. It features a variety of technical articles, such as programming tips and techniques, product 
reviews of new software tools, application development case studies, and interviews with OS/2 industry 
leaders. Examples of articles from recent issues are: 

“Performance Tips and Guidelines” 

“Writing OS/2 Device Drivers” 

“Corel Draw Migration to OS/2 PM” 

“Spotlight on Autodesk” 

IBM employees, customers, and software vendors write articles for the Developer. The magazine is published 
as part of IBM’s Developer Assistance Program, which offers a variety of support services for companies that 
are writing OS/2 applications for resale. 

Subscriptions can be ordered by calling the publisher at 1-800-READ-OS2. IBM employees can subscribe 
through Mechanicsburg’s Systems Library Subscription Service (SLSS), order number G362-0001. 

Articles from the first seven issues of the IBM Personal Systems Developer have been published in a 770-page 
book titled OS/2 Notebook: The Best of the IBM Personal Systems Developer. The book can be bought at a 
local bookstore or by calling Microsoft Press at 1-800-MS-PRESS. 


New Products 

Hardware 

IBM Proprinter 24P 

The IBM Proprinter 24P is a low-cost, 
narrow-carriage, 24-wire, serial dot ma¬ 
trix impact printer for attachment to 
IBM Personal Computers and non-IBM 
PC hosts. The Proprinter 24P produces 
excellent letter-quality printing and bidi¬ 
rectional alignment, in addition to high- 
resolution graphics printing. It offers 
adjustable flat-belt tractors that are easy 
to load and reliable, and a new user- 
friendly operator panel that can be un¬ 
derstood by the novice user. The IBM 
Proprinter 24P is a good price performer 
for the business workstation or home 
use. Additional efficiency is provided 
by the automatic sheet-feed and pull- 
tractor options, both of which are cur¬ 
rently available on the IBM Personal 
System/1™ printer. 

Letter# 191-881, January 22, 1991 


IBM Token-Ring Network 
16/4 Busmaster Server 
Adapter/A 

The IBM Token-Ring Network 16/4 
Busmaster Server Adapter/A is used to 
attach an IBM PS/2 with Micro Chan¬ 
nel® architecture, configured as a 
server, to an IBM Token-Ring Network 
operating at either 16 million or 4 mil¬ 
lion bits per second. The IBM Token- 
Ring Network 16/4 Busmaster Server 
Adapter/A provides high throughput ca¬ 
pability while requiring less host-proces¬ 
sor involvement than previous IBM 
Token-Ring adapters. 

This reduction in host-processor involve¬ 
ment is enabled through the busmaster 
capability of the IBM Token-Ring Net¬ 
work 16/4 Busmaster Server Adapter/A, 
which allows adapter-to-system-memory 
transfer of data independent of the host 
processor. The server’s processor is 
available for other tasks. 


Highlights: 

• Extends life expectancy of server 
hardware by exploiting PS/2 busmas¬ 
ter capability. 

• Reduces requirements for additional 
server hardware as applications or 
workstations are added. 

Letter# 190-208, December 18, 1990. 

Realtime Interface 
Co-Processor Selectable 
Interface Board/A and 
Related Features 

The Realtime Interface Co-Processor 
Selectable Interface Board/A and related 
features provide additional electrical in¬ 
terface and cabling options to the an¬ 
nounced and available Realtime 
Interface Co-Processor Portmaster™ 
Adapter/A and Multiport Adapter Model 
2. The addition of the interface board 
provides electrical interfaces for CCITT 
V.35, CCITT X.21, RS-232-D, and RS- 
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422-A full-duplex communication capa¬ 
bilities. 

Highlights: 

• Provides a flexible, high-function 
communications co-processor when 
used with the Realtime Interface Co¬ 
processor Portmaster Adapter/A or 
Multiport Adapter Model 2 

• Supports single, very high-speed (up 
to 2.04 Mbps on the Portmaster 
Adapter/A or 1.54 Mbps on the 
Multiport Adapter Model 2) full-du¬ 
plex data rates 

• Supports multiple, high speed (up to 
64 Kbps) full-duplex data rates 

Letter# 190-204, December4, 1990. 

Software 

Writing to Write™ Form I 

Writing to Write Form I is a unique and 
revolutionary product which enables sec¬ 
ond grade students to write what they 
can think. It is a balanced curriculum 
where the teacher and the courseware 
are equal instructional partners. The pro¬ 
gram design is instructional, so that the 
students actively participate and learn 
by doing, as opposed to "drill and prac¬ 
tice." Writing to Write Form I encom¬ 
passes the required stages of the 
"process writing" approach: prewriting, 
drafting, editing, revising, publishing 
and sharing. The spiral curriculum, the 
combination and coordination of com¬ 
puter execises, the ancillary print activi¬ 
ties, and the teacher instruction, 
including the stages of process writing, 
makes Writing to Write Form I a 
courseware product which takes full ad¬ 
vantages of technology. It will operate 
within a Teaching and learning with 
Computers (TLC) instructional frame¬ 
work. 

Highlights: 

• Enables the student to understand 
and become proficient in writing as a 


process, including pre-writing, draft¬ 
ing, peer review, revision, editing 
and publishing 

• Assists the student in learning to 
write clearly and effectively 

• Nurtures student creativity as the stu¬ 
dent translates thoughts into writing 

• Nurtures student creativity as the stu¬ 
dent translates thoughts into writing 

• Exposes students to traditional gram¬ 
mar through syntax 

• Promotes student understanding of 
the relationship between writing and 
reading 

• Enhances and builds higher order 
thinking skills 

• Promotes the building of vocabulary 
skills 

• Provides a spiral curriculum with an 
environmental approach that allows 
the learner to build upon the lan¬ 
guage knowledge that the student 
brings to school 

Letter # 291-025, January 29, 1991. 

Intel OS/2 and AIX i860 
Software Development 
Tools for C and FORTRAN 

IBM announced C and FORTRAN com¬ 
piler support for the PS/2 Wizard 
Adapter running under both AIX PS/2 
and OS/2 operating systems. The new 
software packages are vendor-logo pro¬ 
grams that enable software developers 
to develop applications that take advan¬ 
tage of the numeric-intensive processing 
power of the Intel i860 OS/2 micropro¬ 
cessor on the PS/2 Wizard Adapter. 

The Intel i860 OS/2 and AIX Software 
Development Tools for FORTRAN are 
both native compilers that utilize the 
i860 to compile programs. Each pack¬ 
age contains the required tools to enable 
development under OS/2 or AIX operat¬ 
ing systems. The new FORTRAN tools 
replace the Intel i860 OS/2 Software De¬ 


velopment Tools announced by IBM on 
April 3, 1990. 

Highlights: 

• User productivity gains are realized 
through a flexible, desktop solution 
for a broad range of applications that 
typically run on workstation or main¬ 
frame platforms. 

• The customer’s investment is pro¬ 
tected when an upgrade path mi¬ 
grates from a general-purpose PS/2 
system configuration to a technical 
computing platform. 

• The application developer can extend 
the application base to include both 
C and FORTRAN applications, run¬ 
ning under OS/2 or AIX. 

Letter # 290-816, December 18, 1990. 

PS/2 ImagePlus - Statement 
of Direction 

IBM intends to provide a PS/2 LAN- 
based addition to the ImagePlus® fam¬ 
ily. PS/2 ImagePlus will be a complete 
end user configurable implementation of 
ImagePlus in a PS/2 LAN-based envi¬ 
ronment utilizing OS/2 Extended Edi¬ 
tion. 

PS/2 ImagePlus includes image storage 
and retrieval with document, folder, and 
case management. It will provide a com¬ 
prehensive solution for small depart¬ 
ments and work groups of organizations 
that can benefit from ImagePlus without 
having to rely on a host processor con¬ 
nection for image support. 

PS/2 ImagePlus is being designed using 
IBM’s SAA™ and CUA standards as 
implemented in the OS/2 EE Presenta¬ 
tion Manager. It is being developed 
jointly by IBM and Eastman Kodak 
Company. 

Letter # 290-796, December 18, 1990. 
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Automatic SIMM configuration shields the user from 
complex set-up procedures, (page 9) 


In terms of IBM’s priorities, data integrity was at the top of the list in 
developing Micro Channel architecture, (page 14) 


Actual performance should exceed that of 
a comparable small LAN, (page 23) 


A single Presentation Manager call added to your application enables you 
to select any combination of a printer’s features for output, (page 27) 


This perspective will be used to explain how OS/2 and AIX 
compare and contrast with DOS, (page 29) 


There are two distinct types of COBOL compilers for use with PM. (page 42) 


OS/2 EE servers may accept requests from both OS/2 EE requesters 
and DOS Database Requesters concurrently, (page 47) 


With the release of OS/2 LAN Server 1.3, IBM increased performance, 
added new features and improved reliability, (page 55) 


Windows Connection has a full Dynamic Data 
Exchange interface to Windows, (page 58) 


THINKable is the latest addition to the Independence Series 
of products for people with disabilities, (page 75) 
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